[oe] Move IMAGE_BOOT stuff into distro's?

Leon Woestenberg leon.woestenberg at gmail.com
Tue Dec 29 15:47:25 UTC 2009


Hello Phil, all,

On Tue, Dec 29, 2009 at 4:34 PM, Phil Blundell <philb at gnu.org> wrote:
> On Tue, 2009-12-29 at 16:15 +0100, Leon Woestenberg wrote:
>> Why do we hardcode names of default packages in the "image.bbclass"?
>>
>> Now every image recipe that doesn't want these has to know the
>> variables it has to override.
>>
>> Shouldn't this be distro material instead?
>
> Funnily enough I was just discussing a similar issue with Mickey on IRC
> a few minutes ago.
>
> Most of these variables did use to be part of the distro configuration
> but it appears they were moved into image.bbclass by commit
> 9752b780ae9cbe8b36507890d8ee55c439eb2b35.  Presumably this change was
> made for a reason, but it does seem like a retrograde step to me: one
> particular ill-effect of that change is that images built for micro have
> regressed to using udev, whereas previously they were selecting
> busybox-mdev via ${DISTRO_DEV_MANAGER}.  There doesn't seem to be any
> obviously-correct way to restore the previous behaviour.
>
I agree with your analysis.

Don't get me wrong; there must be a valid reason for the approach, I
just don't think we are heading in the right direction.
See reasoning below.

> I have suggested to Mickey that perhaps the TSC would like to consider
> this issue and come up with a coherent policy on how this stuff should
> be managed.
>

Too many assumptions are being made in our classes.
Ideally, the classes should be totally void of hardcoded values.

The image class should be instructed by the user and the distro about
what to install.



Currently, a number of variables have to be overridden to get back to
the previous behaviour.
(This is the "disabling" part I mentioned in my other thread.)
ONLINE_PACKAGE_MANAGEMENT
USE_DEVFS
IMAGE_BOOT


I already disliked our architectures being hard coded (such as
siteinfo) but that's the least annoying part.


Regards,
-- 
Leon




More information about the Openembedded-devel mailing list