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

Otavio Salvador otavio at ossystems.com.br
Mon Feb 25 11:45:15 UTC 2013


On Sun, Feb 24, 2013 at 7:04 PM, Ross Burton <ross.burton at intel.com> wrote:
> On Sunday, 24 February 2013 at 14:06, Otavio Salvador wrote:
>> > 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.
>>
>>
>> The size impact it not negligible; specially for initramfs images but
>> what concerns me even more is the upgrade path from previous users of
>> meta-oe systemd.
>
>
> I obviously didn't make myself clear - the size impact is negligible when you're talking about just the init script - the dependencies on systemd/updatercd could be recommends at most, as the postinst scripts could check what init system they have before calling any tools.  Either way a rescue image that boots using busybox init shouldn't have systemd, clearly.
>> I'd like to have an upgrade path.
>
> Well, strictly speaking oe-core itself doesn't have an upgrade path to consider… Why can't any distros that shipped with meta-systemd (or just in meta-systemd) have an include that injects the RPROVIDES/RREPLACES/RCONFLICTS for the packages that they enabled?

Well, in this way why meta-oe or meta-systemd fork systemd code and do
it as previously? I think this is the wrong route.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br




More information about the Openembedded-core mailing list