[OE-core] RFE: make the init manager an image feature (again)

Khem Raj raj.khem at gmail.com
Tue Feb 26 06:45:29 UTC 2013


On Sun, Feb 24, 2013 at 2:37 AM, Ross Burton <ross.burton at intel.com> wrote:
> Hi,
>
> Just brainstorming out loud, but here's a suggestion that might just please everyone:
>
> A virtual provider for the init manager, which can be overridden per-image (for main / rescue images).

Yes I was thinking about it too but it has to be made one off case.
Since we wont be able to support all combinations


>
> DISTRO_FEATURES contains the init script *style* that you want: sysvinit or systemd.  These are not mutually exclusive so specifying both will get you both directly in packages that support both.  I'm still not convinced we need to split these out into separate packages, the size impact is practically negligible and the dependencies are effectively redundant as you'll have trouble booting without an init system.  Instead the postinsts should wrap the initscript fragments in checks.

systemd lives fine with initscripts. In some cases the adhoc unit
files just call these initscripts so in a way systemd does
expect the initscripts to be around. So systemd is sort of addon and
thats why ${PN}-systemd worked well. So we can have
a perfect sysvinit based system and then we replace it with systemd
and add the ${PN}-systemd packages into image and it becomes
a systemd based image. I think as porting happens this case of
wrapping initscripts into systemd service files will continue
unless individual packages get their own unit files which are
rewritten and do not use initscripts anymore.

>
> Those distro features will also be used to enable/disable features in the source, so enabling systemd may well lead to libsystemd-* libraries sneaking into your rescue image.  The systemd libraries will have to be reviewed to verify that installing one of them doesn't pull in systemd itself.
>
> Here's the fun bit - we can't have two builds of udev in the same distro, and that's what could happen, so I think we'll need to cut down to one udev instead of two.

well we can make a udev recipe which uses exact sources used by systemd.

>
> I'm not entirely convinced this is a good plan yet myself though…
>
> Ross
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




More information about the Openembedded-core mailing list