On Sun, Feb 24, 2013 at 7:04 PM, Ross Burton <ross.bur...@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: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
