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

Martin Jansa martin.jansa at gmail.com
Mon Feb 25 07:38:52 UTC 2013


On Sun, Feb 24, 2013 at 10:04:42PM +0000, Ross Burton 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?

That would force multiple distro layers to maintain many .bbappends with
just RPROVIDES/RREPLACES/RCONFLICTS and PRINC bump maintaned forever.

It was pain to rename .bbappends in meta-systemd after each .bb upgrade,
so if we have to do that, then we should rather keep meta-systemd as
layer so that we can share .bbappend maintenance for all distributions in
one place.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130225/4b03e025/attachment-0002.sig>


More information about the Openembedded-core mailing list