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: [email protected]

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to