Debian Buster release to partially drop non-systemd support

Ian Jackson ijackson at chiark.greenend.org.uk
Tue Oct 16 17:01:50 BST 2018


(Dropping d-devel so we can concentrate on technical approaches.)

Thorsten Glaser writes ("Re: Debian Buster release to partially drop non-systemd support"):
> On Tue, 16 Oct 2018, Adam Borowski wrote:
> > 2. You lose basic functionality like being able to shutdown from a GUI.
> 
> Oh? For me, Ctrl-Alt-Backspace+Ctrl-Alt-Del works.

Yes, maybe.  But it would be nice for the pointyclicky thing to work
too.

Personally, on my own laptop, the wifi configuration is done with
network-manager and the screen brightness is done mate-power-manager.
Both of those depend on elogind.  Yes, you can do some of this with
acpi instead, and for wifi you can use the wpa stuff directly.

For the avoidance of any doubt, I am not saying that you will have to
run a system with elogind or the like.  I definitely want people who
don't want to, to be able to carry on.

> > > 1. systemd-shim is not necessary, even for DEs (except GNOME3).
> > 
> > Alas, dependency chains say otherwise.
> 
> Huh?

A big problem is libpam-systemd.  That is needed for
 * /run/user/UID
 * the `user session' dbus

The latter depends on the former.  The former is actually a good idea,
but we don't have an implementation of it that isn't in something like
elogind - although one could exist.  The latter is used by some
desktoppy things nowadays and tends to get into dependency chains.
(NB `user session' is supposed to have a longer lifetime and broader
scope than `login session'.)

These two facilities don't seem inherently bad ideas.

IMO it would be easier to provide these things than to play
whack-a-mole with the things that depend on them.

> > Other pieces are some power management that has been moved into
> > logind, etc.
> 
> Eh? The acpi command works, and sysfs writes do so, too…

Indeed.  Suspend on my laptop works that way.  But it would be nice to
have soemthing that does not involve the user editing acpi recipes and
shell scripts.

> > > 2. sysvinit-core is very stable and do not need new uploads.
> > 
> > Exactly!  Almost any changes in recent years were entirely because "systemd
> > wants X".  Thus, no wonders people are angry because of unnecessary work.
> 
> Hm. I didn't follow those changes, but if it's that's good point.

I think it would be really helpful if we had active sysvinit
maintenance in Debian.  There is a long backlog of bugs; there's a new
upstream version which needs packaging.

And it's a really bad look to have systemd people actually doing the
uploads.

Ian.




More information about the Debian-init-diversity mailing list