On 05/01/2013 12:04 PM, Fabio Erculiani wrote: > PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. > THIS IS NOT A POST AGAINST OPENRC.
Amen > With the release of Sabayon 13.04 [1] and thanks to the efforts I put > into the systemd-love overlay [2], systemd has become much more > accessible and easy to migrate to/from openrc. Both are able to > happily coexist and logind/consolekit detection is now done at > runtime. > It is sad to say that the "territoriality" in base-system (and > toolchain) is not allowing any kind of progress [3] [4]. This is > nothing new, by the way. > > There are several components that need patching in order to work as > expected with systemd: > - polkit needs a patch that enables runtime detection of logind/consolekit > - pambase needs to drop USE=systemd and always enable the optional > module pam_systemd.so > - genkernel needs to migrate to *udev (or as I did, provide a --udev > genkernel option), mdev is unable to properly activate LVM volumes and > LVM is actually working by miracle with openrc. Alternatively, we > should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. > - networkmanager need not to install/remove files depending on > USE=systemd but rather detect systemd at runtime, which is a 3 lines > script. Sounds sensible. > - openrc-settingsd needs to support eselect-settingsd, which makes > possible to switch the settingsd implementation at runtime, between > openrc and systemd. This also removes the silly conflict between > openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? > - genkernel should at least support plymouth (work in progress my side) Looking forward to it. > - other ~490 systemd units are missing at this time and writing them > could also be a great GSoC project (don't look at me, I'm busy > enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. > It looks like there is some consensus on the effort of making systemd > more accessible, while there are problems with submitting bugs about > new systemd units of the sort that maintainers just_dont_answer(tm). > In this case, I am just giving 3 weeks grace period for maintainers to > answer and then I usually go ahead adding units (I'm in systemd@ after > all). See above. > The only remaining problem is about eselect-sysvinit, for this reason, > I am probably going to create a new separate pkg called > _sysvinit-next_, that contains all the fun stuff many developers were > not allowed to commit (besides my needs, there is also the need of > splitting sysvinit due to the issues reported in [4]). I am sure that > a masked alternative sysvinit ebuild won't hurt anybody and will make > Gentoo a bit more fun to use. Exactly, which is the problem at hand? I'd like to be able to safely switch back and forth sysvinit and bb-init as well. > The final outcome will hopefully be: > - easier to migrate from/to systemd, at runtime, with NO recompilation > at all (just enable USE=systemd and switch the device manager from > *udev to systemd -- unless somebody wants to drop the udev part from > systemd, if at all possible) > - we give the users the right to choose without driving them nuts with > weird emerge-fu. > - we make possible to support new init systems in future, and even > specific init wrappers (bootchart anyone?) Here! o/ Currently in my list are - bootchart2 (as an add-on to the other init systems) - bb-init (requires different custom inittab) - runit (openrc can use it instead thanks to benda xu past GSoC) > - we prepare the path towards a painless migration from consolekit > (deprecated for long time now) to logind (we probably need to fork it > off the systemd pkg -- upstream projects are _dropping_ consolekit > support right now!) Again it is something I consider an option for a GSoC project, we have already some openrc variant for other systemd-originated daemons in our git. > - we put back some fun into Gentoo That's always good. > If you want to see a working implementation of my systemd-love > efforts, just go download [1] and see things working yourself. Thank you a lot for your positive attitude and the huge effort =) lu
