On 05/01/13 05:04, Fabio Erculiani wrote: > PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. > THIS IS NOT A POST AGAINST OPENRC. > > 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. > - networkmanager need not to install/remove files depending on > USE=systemd but rather detect systemd at runtime, which is a 3 lines > script. > - 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. > - genkernel should at least support plymouth (work in progress my side) > - 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). > > All this would come with no cost for the current openrc state > (actually, my initramfs speed improvements patches in genkernel.git > also benefit openrc). > If Gentoo is about choice, we should give our users the right to > choose between the init system they like the most. > > 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). > > 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. > > 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?) > - 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!) > - we put back some fun into Gentoo > > If you want to see a working implementation of my systemd-love > efforts, just go download [1] and see things working yourself. > > [1] http://www.sabayon.org/release/press-release-sabayon-1304 > [2] https://github.com/Sabayon/systemd-love > [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 > [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615 > > Cheers, > Isn't there a tracker (and if not, why have you not created one yet :P )
-- -- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
