On Sat, Feb 16, 2013 at 12:34:58PM +0000, Richard Purdie wrote: > On Sat, 2013-02-16 at 12:57 +0100, Enrico Scholz wrote: > > Richard Purdie <richard.pur...@linuxfoundation.org> writes: > > >> it would be nice when the decision to make the init manager a > > >> distribution > > >> feature will be reverted to the old oe-meta mechanism. > > > > > > The trouble is that by making it an "image feature", people will > > > expect *everything* to work properly and to be able to have fully > > > functional sysvinit and systemd variants of images. > > > > I do not see an obvious reason why fully functional sysvinit, systemd and > > perhaps upstart image variants based on the same distribution/package set > > are impossible. > > > > Of course, not "everything" will work. But initmgr being a distribution > > feature makes some things completely impossible. > > > > > We already see this expectation. > > > > IMO, removal of features just to lower expectations is the completely > > wrong way. > > meta-oe earned a *horrendous* reputation because of the way systemd was > implemented there. I believe (as do a number of others) that it has > damaged OE's reputation and usability and actively hurts new users. Yes, > the people who use systemd and meta-oe were happy. People who didn't > want systemd were not. There continues to be a fairly toxic mix of > distro policy mingled in with the recipes in there although good > progress is being made in fixing that and I'm grateful to the people > who've noticed and taken on that work (and done previous work like the > separation of meta-systemd).
I was using sysvinit images even with systemd in meta-oe, setting 2 VIRTUAL_RUNTIME variables and 1 .bbappend was enough to keep sysvinit images working. I agree that we were missing documentation for that and new users weren't able to figure it out for themselves. > It was clear systemd needed to move into the core but also become more > configurable to work for everyone. I don't want to remove features, I do > want to talk about whether there is a better way we can fulfil certain > uses cases, particularly with a focus on usability. I was talking with Ross about systemd as DISTRO_FEATURE, I agreed that it's fine to have it as DISTRO_FEATURE but I didn't expect that it also means that he wants to move PN-systemd to PN without upgrade path and possibility to create image without PN-systemd packages. My expectation was that systemd in DISTRO_FEATURES will enable systemd.bbclass functionality (same functionality as meta-systemd/system.bbclass had), not that it will force systemd and only systemd. Like with "3g" in DISTRO_FEATURES we expect that DISTRO supports 3g but not that every possible image and MACHINE will provide 3g functionality. I can imagine distribution with sysvinit+upstart+systemd in DISTRO_FEATURES if they are careful enough to prepare images with only right packages. > > > Trying to explain to people what the limitations are, what is expected > > > to work and what isn't will be difficult. > > > > OpenEmbedded is not an end-user distribution but for people who are > > willing to invest some learning effort. Trying to limit ourself on the > > lowest common ground is not desirable imo. > > I did not say we're not going to support your use case. I'm asking if we > can summarise exactly what the problem is and whether there is another > way we can get there which isn't going to surprise as many people and be > easier to use. > > I'm actually moderately annoyed that throughout the various discussions > about systemd and how we'd get it into OE-Core nobody actually mentioned > these specific requirements until very late in the implementation. I think we all replied on first patch to move from PN-systemd to PN. > At the bare minimum, we actually need to document the usecases people > are using and require. Yes, you know your usecase but you need to take > some responsibility for ensuring its documented and known about else it > will continue to get broken time and time again. > > > > For that reason I'd rather see this done in a different way, for > > > example blacklisting the problematic systemd dependencies at image > > > generation time with some kind of stronger BAD_RECOMMENDS code. > > > > Assuming we are able to break the hard dependencies, what is with package > > scripts which require programs, files or directories from these deps? Do > > we need a way to differ between good and bad script failures then? > > At the technical level there is little difference from packaging these > things separately to avoid specific dependencies and explicitly telling > the package manager to avoid that dependency instead. > > Equally there are other cases where people do want to break specific > dependencies so this could help us in that area too. > > Perhaps there is a dependency we need to drop to a Recommends level, > then use BAD_RECOMMENDS to handy that. We do need to document why we do > that and how it is expected to be used. I think the problem Enrico describes is that systemctl calls were contained to PN-systemd postinst/prerm scripts, now with systemd support moved from PN-systemd to PN you have to move postinst/prerm too and if you allow runtime dependency on systemd package to be broken, then you need to wrap each postinst/prerm script with check to see if e.g. systemctl exists on target image. > > Sounds extremely hacky and fragile... > > It depends on the implementation. > > Having initscripts in individual packages and having to play tricks to > ensure the right sets of packages get installed is rather hacky and > fragile. Automatic RRECOMMENDS from systemd.class was working fine, only other place where you needed to make sure all bits are in place was packagegroup-core-boot. I wasn't even using automatic RRECOMMEND but small packagegroup recipe to pull only systemd support for packages where I wanted it. It was more flexible and allowed me for example to install only ntpdate without systemd support: ntpdate works fine for people who wants to occasionally sync their time ntpdate-systemd is better for people who want to sync on every boot -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
