Move IMAGE_BOOT stuff into distro's?

Move IMAGE_BOOT stuff into distro's?

[Leon Woestenberg]

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?

#
# udev, devfsd, busybox-mdev (from busybox) or none
#
IMAGE_DEV_MANAGER ?= "${@base_contains("MACHINE_FEATURES", "kernel26",
 "udev","",d)} "
#
# sysvinit, upstart
#
IMAGE_INIT_MANAGER ?= "sysvinit sysvinit-pidof"
IMAGE_INITSCRIPTS ?= "initscripts"
#
# tinylogin, getty
#
IMAGE_LOGIN_MANAGER ?= "tinylogin"

IMAGE_KEEPROOTFS ?= ""
IMAGE_KEEPROOTFS[doc] = "Set to non-empty to keep ${IMAGE_ROOTFS}
around after image creation."

IMAGE_BOOT ?= "${IMAGE_INITSCRIPTS} \
${IMAGE_DEV_MANAGER} \
${IMAGE_INIT_MANAGER} \
${IMAGE_LOGIN_MANAGER} "

Regards,
-- 
Leon

Re: Move IMAGE_BOOT stuff into distro's?

[Phil Blundell]

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 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.

p.

Re: Move IMAGE_BOOT stuff into distro's?

[Leon Woestenberg]

Hello Phil, all,

On Tue, Dec 29, 2009 at 4:34 PM, Phil Blundell <philb@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

Re: Move IMAGE_BOOT stuff into distro's?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29-12-09 16:15, 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?

No, since these are things you want to be able to manage on a per image
basis, not distro wide. I don't want to create a whole 'new' distro just
to try mdev instead of udev or use tinylogin instead of shadow, etc.
When we made that change we discussed what the default values for those
vars should be and it was agreed they should provide sane defaults.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLOk5tMkyGM64RGpERAudNAJ4wC8aftgrdzk8BLa3FL2w7XC9l7wCfb9CN
2qCrG0DL86Qs+mPkB+yO9hE=
=+T+/
-----END PGP SIGNATURE-----

Re: Move IMAGE_BOOT stuff into distro's?

[Leon Woestenberg]

Hello Koen,

On Tue, Dec 29, 2009 at 7:46 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 29-12-09 16:15, 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?
>
> No, since these are things you want to be able to manage on a per image
> basis, not distro wide. I don't want to create a whole 'new' distro just
> to try mdev instead of udev or use tinylogin instead of shadow, etc.
> When we made that change we discussed what the default values for those
> vars should be and it was agreed they should provide sane defaults.
>
OK understood, apparantly we want to have a generic image base
containing udev, a login, shadow etc.
that is distro-indepent.

Can we remove that from the image class, and move into a
image-boot.inc or something?

Regards,
-- 
Leon

Re: Move IMAGE_BOOT stuff into distro's?

[Khem Raj]

On Tue, Dec 29, 2009 at 11:44 AM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Hello Koen,
>
> On Tue, Dec 29, 2009 at 7:46 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 29-12-09 16:15, 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?
>>
>> No, since these are things you want to be able to manage on a per image
>> basis, not distro wide. I don't want to create a whole 'new' distro just
>> to try mdev instead of udev or use tinylogin instead of shadow, etc.
>> When we made that change we discussed what the default values for those
>> vars should be and it was agreed they should provide sane defaults.
>>
> OK understood, apparantly we want to have a generic image base
> containing udev, a login, shadow etc.
> that is distro-indepent.
>
> Can we remove that from the image class, and move into a
> image-boot.inc or something?

or create a class base-image without these defaults
and let image class include base-image plus these IMAGE_* defaults
that way you dont have to modiy recipes which inherit image which are many
instead one can modify the recipes which dont need the IMAGE_* defaults
to inherit from base-image

-Khem

Re: Move IMAGE_BOOT stuff into distro's?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29-12-09 23:42, Khem Raj wrote:
> On Tue, Dec 29, 2009 at 11:44 AM, Leon Woestenberg
> <leon.woestenberg@gmail.com> wrote:
>> Hello Koen,
>>
>> On Tue, Dec 29, 2009 at 7:46 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 29-12-09 16:15, 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?
>>>
>>> No, since these are things you want to be able to manage on a per image
>>> basis, not distro wide. I don't want to create a whole 'new' distro just
>>> to try mdev instead of udev or use tinylogin instead of shadow, etc.
>>> When we made that change we discussed what the default values for those
>>> vars should be and it was agreed they should provide sane defaults.
>>>
>> OK understood, apparantly we want to have a generic image base
>> containing udev, a login, shadow etc.
>> that is distro-indepent.
>>
>> Can we remove that from the image class, and move into a
>> image-boot.inc or something?

What's the problem with setting 3 vars to "" in your helloworld image?

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLOxPoMkyGM64RGpERAi7PAJwMupouhtOhOH9pznDzucVaTHdBAACfYSua
B0hsO7h9Y0Y60IZJcu2zquw=
=HVbp
-----END PGP SIGNATURE-----

Re: Move IMAGE_BOOT stuff into distro's?

[Frans Meulenbroeks]

2009/12/30 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 29-12-09 23:42, Khem Raj wrote:
>> On Tue, Dec 29, 2009 at 11:44 AM, Leon Woestenberg
>> <leon.woestenberg@gmail.com> wrote:
>>> Hello Koen,
>>>
>>> On Tue, Dec 29, 2009 at 7:46 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 29-12-09 16:15, 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?
>>>>
>>>> No, since these are things you want to be able to manage on a per image
>>>> basis, not distro wide. I don't want to create a whole 'new' distro just
>>>> to try mdev instead of udev or use tinylogin instead of shadow, etc.
>>>> When we made that change we discussed what the default values for those
>>>> vars should be and it was agreed they should provide sane defaults.
>>>>
>>> OK understood, apparantly we want to have a generic image base
>>> containing udev, a login, shadow etc.
>>> that is distro-indepent.
>>>
>>> Can we remove that from the image class, and move into a
>>> image-boot.inc or something?
>
> What's the problem with setting 3 vars to "" in your helloworld image?
>

What is wrong with the philosophy to have a bare minimal system and
add the three images to those who need them (and allow them to derive
from a base image that has these 3 packages.

E.g. one could then derive/extend base_image if you want to.

My philosophy is to keep things generic and specialize when going to
more specific situations, not to have a partially specialized solution
which has to be made more generic.fro a specific situation.

Frans.

Re: Move IMAGE_BOOT stuff into distro's?

[Leon Woestenberg]

Hello,

On Wed, Dec 30, 2009 at 9:48 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>> OK understood, apparantly we want to have a generic image base
>>> containing udev, a login, shadow etc.
>>> that is distro-indepent.
>>>
>>> Can we remove that from the image class, and move into a
>>> image-boot.inc or something?
>
> What's the problem with setting 3 vars to "" in your helloworld image?
>
Let me counter that question: What's the problem with bitrot and poor
design if the end result still works?

Of course it's easy to add 3 vars, that's not my point. The point is
those 3 vars do not need to be hard coded by
default in a class.


Design:

The class implements the work to be done.
The recipes describe what work has to be done indirectly.

Design problem:

The class now contains hard-coded package names directly.

The image recipes have to know the internals of the class in order to
revert to fully customizable behaviour.


Of course I could stop being frustrated about this and happily add 3
vars to my image and not care about this anymore.


Regards,
-- 
Leon

Re: Move IMAGE_BOOT stuff into distro's?

[Frans Meulenbroeks]

2009/12/30 Leon Woestenberg <leon.woestenberg@gmail.com>:
> Hello,
>
> On Wed, Dec 30, 2009 at 9:48 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>>> OK understood, apparantly we want to have a generic image base
>>>> containing udev, a login, shadow etc.
>>>> that is distro-indepent.
>>>>
>>>> Can we remove that from the image class, and move into a
>>>> image-boot.inc or something?
>>
>> What's the problem with setting 3 vars to "" in your helloworld image?
>>
> Let me counter that question: What's the problem with bitrot and poor
> design if the end result still works?
>
> Of course it's easy to add 3 vars, that's not my point. The point is
> those 3 vars do not need to be hard coded by
> default in a class.
>
>
> Design:
>
> The class implements the work to be done.
> The recipes describe what work has to be done indirectly.
>
> Design problem:
>
> The class now contains hard-coded package names directly.
>
> The image recipes have to know the internals of the class in order to
> revert to fully customizable behaviour.
>
>
> Of course I could stop being frustrated about this and happily add 3
> vars to my image and not care about this anymore.
>
>
> Regards,
> --
> Leon

Leon, I agree with your line of reasoning. Classes specify the how and
recipes specify the what.

May I propose to put this on the agenda of the TSC ?

Frans.