overriding a class in custom layer

[Joshua Immanuel]

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

[Christopher Larson]

Ensure that your layer is before the other in BBLAYERS.
--
Christopher Larson

Post by Joshua Immanuel
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
https://lists.yoctoproject.org/listinfo/yocto

[Joshua Immanuel]

Hello Christopher,

Thanks for the reply.

Post by Christopher Larson
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

[Christopher Larson]

Post by Joshua Immanuel
Hello Christopher,
Thanks for the reply.

Post by Christopher Larson
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.

[Paul Eggleton]

Post by Christopher Larson
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

[Christopher Larson]

Post by Paul Eggleton
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.

[Joshua Immanuel]

Hello Paul,

Thanks for the reply.

Post by Paul Eggleton
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

[Paul Eggleton]

Post by Joshua Immanuel

Post by Paul Eggleton
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

[Chris Larson]

On Wed, Jan 25, 2012 at 8:56 AM, Paul Eggleton

Post by Paul Eggleton

Post by Joshua Immanuel

Post by Paul Eggleton
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.