Re: [gentoo-dev] eselect init

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> There is a new version of eselect-init in the systemd-love overlay to play with.
> The new version saw the following major changes:
> 
> - the /sbin/init (aka the symlink that eselect-init handles) can be
> changed to whatever one wants through make.conf [1] (this is a compile
> time option, as documented in the eclass)

Why do we need to mess with /sbin/init at all?

I like the suggestion that came up here on the list a while back, have
the eselect init module install its own symlink at, say, /sbin/einit.
You would still have to have the user edit their boot loader
configuration file one time if they want to use this, but this makes it
completely opt-in.

The other advantage of this is you don't have to mess with any  init
system ebuilds at all.

> - the wrapper and its code paths are now documented in the
> eselect-init eclass [2] [3]

This eclass could go away entirely if you don't try to control
/sbin/init.

> If you intend to use switch between systemd to openrc (and vice
> versa), make sure to install the rest of the packages in that overlay.
> At the moment, if you want to switch, you also need to use
> eselect-settingsd. However, I am planning to drop eselect-settingsd:
> openrc-settingsd and systemd share the same settingsd dbus interface
> while they call different executables, systemd initializes its dbus
> services without relying on dbus activation, so the Exec= part of the
> service descriptor file is currently set to /bin/false, this rings a
> bell :D, because it is possible to replace /bin/false with a script
> that starts the respective services when dbus activation is used
> (which means that systemd hasn't booted the system). This would make
> possible to remove the blocker dependency in openrc-settingsd and
> systemd somehow.

Keep up the good work; the more simple we can make the integration the
better it will be.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]