Re: [gentoo-dev] Making systemd more accessible to "normal" users

[Luca Barbato]

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