overriding a class in custom layer

overriding a class in custom layer

[Joshua Immanuel]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

Hello all,
	What is the preferred way of overriding an existing class in the 'meta'
layer. I tried to add the existing class (say image_types.bbclass) to my
custom layer and did some modifications to it. But while trying to build
the image, only the original class gets inherited instead of the one in
my custom layer. How do I force the bitbake to use the modified class
file in the custom layer? 

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: overriding a class in custom layer

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Ensure that your layer is before the other in BBLAYERS.

-- 
Christopher Larson


On Tuesday, January 24, 2012 at 3:47 AM, Joshua Immanuel wrote:

> Hello all,
> What is the preferred way of overriding an existing class in the 'meta'
> layer. I tried to add the existing class (say image_types.bbclass) to my
> custom layer and did some modifications to it. But while trying to build
> the image, only the original class gets inherited instead of the one in
> my custom layer. How do I force the bitbake to use the modified class
> file in the custom layer? 
> 
> Regards
> Joshua
> -- 
> Joshua Immanuel
> HiPro IT Solutions Private Limited
> http://hipro.co.in
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org (mailto:yocto@yoctoproject.org)
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 



[-- Attachment #2: Type: text/html, Size: 1719 bytes --]

Re: overriding a class in custom layer

[Joshua Immanuel]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

Hello Christopher,

Thanks for the reply.

On Tue, 2012-01-24 at 07:07 -0700, Christopher Larson wrote:
> Ensure that your layer is before the other in BBLAYERS.

As you mentioned reordering BBLAYERS to have my custom layer before
'meta' layer solved the issue. I was of the notion that setting
BBFILE_PRIORITY higher for my layer would be sufficient.

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: overriding a class in custom layer

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Tuesday, January 24, 2012 at 7:24 AM, Joshua Immanuel wrote:
> Hello Christopher,
> 
> Thanks for the reply.
> 
> On Tue, 2012-01-24 at 07:07 -0700, Christopher Larson wrote:
> > Ensure that your layer is before the other in BBLAYERS.
> 
> 
> As you mentioned reordering BBLAYERS to have my custom layer before
> 'meta' layer solved the issue. I was of the notion that setting
> BBFILE_PRIORITY higher for my layer would be sufficient.
> 
> 


Unfortunately, BBFILE_PRIORITY only affects the choice of what *recipes* to use between the different layers, not config files or classes. The latter are found via BBPATH, which is incrementally appended to by each layer.conf. This separation is unfortunate, as it means part of the layer priority is in the user's hands (or the script generating bblayers.conf, if using one), and part is in the layers' hands (layer.conf), but that's the way it is for now.

-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1386 bytes --]

Re: overriding a class in custom layer

[Paul Eggleton]

On Tuesday 24 January 2012 07:32:47 Christopher Larson wrote:
> Unfortunately, BBFILE_PRIORITY only affects the choice of what *recipes* to
> use between the different layers, not config files or classes. The latter
> are found via BBPATH, which is incrementally appended to by each
> layer.conf. This separation is unfortunate, as it means part of the layer
> priority is in the user's hands (or the script generating bblayers.conf, if
> using one), and part is in the layers' hands (layer.conf), but that's the
> way it is for now.

I'd also say, what is in the classes is intended to work for everyone, so if 
there's something in the core classes that is not working well for your 
situation we'd really like to hear about it - hopefully we can incorporate 
whatever changes you need and you can avoid having to overlay the entire 
class.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: overriding a class in custom layer

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Tuesday, January 24, 2012 at 9:17 AM, Paul Eggleton wrote:
> On Tuesday 24 January 2012 07:32:47 Christopher Larson wrote:
> 
> 
> 
> 
> I'd also say, what is in the classes is intended to work for everyone, so if
> there's something in the core classes that is not working well for your
> situation we'd really like to hear about it - hopefully we can incorporate
> whatever changes you need and you can avoid having to overlay the entire
> class.

This is true, but still sounds like an excuse to me. Either we support class and config file overriding or we don't. If we do, we should support it properly and well. 

-- 
Christopher Larson


[-- Attachment #2: Type: text/html, Size: 2469 bytes --]

Re: overriding a class in custom layer

[Joshua Immanuel]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Hello Paul,

Thanks for the reply.

On Tue, 2012-01-24 at 16:17 +0000, Paul Eggleton wrote:
> I'd also say, what is in the classes is intended to work for everyone,
> so if there's something in the core classes that is not working well
> for your situation we'd really like to hear about it - hopefully we
> can incorporate whatever changes you need and you can avoid having to
> overlay the entire class. 

At present when we build an image, everything gets under one partition.
For my use case I need two images (denoting different partitions)
     1. rootfs image (mount point: '/', mounted as ro)
     2. data partition image (mount point: say '/data' mounted as rw)

While generating the image, I construct the /etc/fstab file manually by
representing filesystems by their uuids (generated using uuidgen). So,
to set this uuid in generated image I try to override the
image_types.bbclass and using tune2fs I set the uuid for the generated
images.

Is there any other better way of doing this?

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: overriding a class in custom layer

[Paul Eggleton]

On Wednesday 25 January 2012 11:03:16 Joshua Immanuel wrote:
> On Tue, 2012-01-24 at 16:17 +0000, Paul Eggleton wrote:
> > I'd also say, what is in the classes is intended to work for everyone,
> > so if there's something in the core classes that is not working well
> > for your situation we'd really like to hear about it - hopefully we
> > can incorporate whatever changes you need and you can avoid having to
> > overlay the entire class.
> 
> At present when we build an image, everything gets under one partition.
> For my use case I need two images (denoting different partitions)
>      1. rootfs image (mount point: '/', mounted as ro)
>      2. data partition image (mount point: say '/data' mounted as rw)
> 
> While generating the image, I construct the /etc/fstab file manually by
> representing filesystems by their uuids (generated using uuidgen). So,
> to set this uuid in generated image I try to override the
> image_types.bbclass and using tune2fs I set the uuid for the generated
> images.

AFAIK we don't already have the ability to do this, but it sounds very useful. 
If it can be something that can be enabled and configured relatively easily 
then it would be great to have in OE-Core as I can imagine others making use 
of it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: overriding a class in custom layer

[Chris Larson]

On Wed, Jan 25, 2012 at 8:56 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 25 January 2012 11:03:16 Joshua Immanuel wrote:
>> On Tue, 2012-01-24 at 16:17 +0000, Paul Eggleton wrote:
>> > I'd also say, what is in the classes is intended to work for everyone,
>> > so if there's something in the core classes that is not working well
>> > for your situation we'd really like to hear about it - hopefully we
>> > can incorporate whatever changes you need and you can avoid having to
>> > overlay the entire class.
>>
>> At present when we build an image, everything gets under one partition.
>> For my use case I need two images (denoting different partitions)
>>      1. rootfs image (mount point: '/', mounted as ro)
>>      2. data partition image (mount point: say '/data' mounted as rw)
>>
>> While generating the image, I construct the /etc/fstab file manually by
>> representing filesystems by their uuids (generated using uuidgen). So,
>> to set this uuid in generated image I try to override the
>> image_types.bbclass and using tune2fs I set the uuid for the generated
>> images.
>
> AFAIK we don't already have the ability to do this, but it sounds very useful.
> If it can be something that can be enabled and configured relatively easily
> then it would be great to have in OE-Core as I can imagine others making use
> of it.


That does sound nice. Actually, it'd also be nice to come up with a
declarative way to express info about partitioning in general, which
would ideally result in an automatic split up of the rootfs across
those partitions when appropriate. Hmmm.
-- 
Christopher Larson