[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Integration with systemd


I thought about just silently unsubscribing from debian-devel… but as I 
got the impression that almost no one argues for the freedom to choose 
the init system here in this thread, I decided to speak up:

Theodore Y. Ts'o - 31.10.19, 00:57:48 CET:
> And if we do this in core Debian infrastructure, such as say, in dpkg,
> then that's *really* different.  That's completely ruling out
> sysvinit.  And that to me is different from something like "GNOME no
> longer works on sysvinit" (until someone enhances elogind).  In that
> case, it's the GNOME Project which screwed over sysvinit, not Debian
> --- and we're just saying that it's not the GNOME Debian packaging
> team which is obligated to fix things up.
> But the dpkg maintainer making a change which screws over sysvinit
> *feels* different, both in that it affects all Debian installations,
> versus just the ones using a particular GUI, and whether it was Debian
> or GNOME that made that particular decision.
> Let me be clear, my personal opinion is that Lennart, and the
> acceptance of systemd by the vast majority of the major distributions,
> means that eventually, most upstreams will be using more and more
> systemd features, and people who like sysvinit should just get over
> it.  But whether we should accelerate that transition, or let it
> happen at a more natural pace, is something which IMHO, needs to be
> handled on a case by case basis.  Exactly how much of a win do we get
> if we use a particular systemd feature in core Debian packaging?  How
> hard is it to emulate that for non-systemd systems?  I don't think
> that decision can be made in the abstract, unless we as an entire
> project want to vote to deliberately, and with malice aforethought,
> kill off sysvinit support in Debian.

While I do not expect maintainers of Debian packages to implement 
support for alternate init systems themselves, I still believe if 
someone works constructively and consistently on making such support 
available in Debian, it would be good to be inclusive enough to allow 
him or her to do this work and find a good way to integrate.

Like with elogind.

Refusing to work together constructively due to emotional exhaustion 
even tough Mark did all he can to remain as constructive and supportive 
as he could… is understandable, but ultimately does not help and may 
ultimately alienate those who use Debian with an alternative init 

For me one of the core issues is that with how systemd is designed it 
can be challenging to find a win-win solution, at least if you like to 
use all its features. Systemd appears to be an all-or-nothing-approach. 
And thus the analogy you made, Ted, that Josh judged and silenced as 
"gratuitous flame" appeared to be perfectly valid to me as for it 
described what I see happening here. In this concrete example Mark came 
up with several such win-win solutions to the best of his ability 

Making core Debian infrastructure dependent on Systemd will very likely 
alienate me away from Debian. This laptop, for the sake of packaging 
flexible I/O tester, is the last of my machines still running on Debian. 
All the others are running Devuan. I am not looking back. I have no 
intention what so ever to switch back to Systemd again. For that reason 
I for example use unbound instead of knot-resolver. Cause I still have a 
choice which upstream projects to choose. If I would not be able to run 
Debian with sysvinit or runit in the end I might also drop my packaging 
and at least some other contributions to Debian at one point in time. If 
Debian is not inclusive enough for me to run it the way I like it to, 
what is the point of contributing to it any longer unless I can still 
use the Debian packaging as a base for the package in Devuan?

Making core Debian infrastructure dependent on Systemd would also deepen 
the split between Debian and Devuan. So far it has been possible to keep 
the differences at a minimum, making Devuan more of a slight variation to 
Debian instead of a fork that would develop in a different direction. 
Keeping the differences minimal is also an intention of Devuan project 
members as far as I got.

As for upstream I'd wait for what actually would really happen instead 
of trying to predict the future. So far, I am able to run all I need on 
sysvinit and/or openrc+sysvinit based systems. Others are to¹. That even 
includes third party software like rspamd, now available in Debian too, 
and I also expect the Elastic Stack to work. Cause in the end, most of 
them are services which do not really care for how they have been 

Also the KDE project shows no signs limiting itself to Systemd based 
systems. The Plasma desktop needs some logind, but that is basically it. 
I expect that to stay this way at least for as long as FreeBSD is 
supported and quite some KDE applications even run and in part are also 
supported on Windows. For the KDE project portability is a feature not a 

Even GNOME Evolution groupware client starts background services with an 
alternate init systems again instead of solely relying on Systemd 
services. Some time ago it did… and I replaced those with a runit 
services. But those are no longer necessary.

A lot of other services are also supported and ported to some BSD as 
well or even coming from there, like OpenSSH. It is highly unlikely that 
those will depend on Systemd in a way that it would not be possible to 
use them with an alternate init system.

Again, for quite some projects / developers portability is a feature not 
a hindrance.

In the end this is still free software and upstream projects can choose 
their path. To that extent, Ted, your analogy does not apply.

As to a GR, as long as it does not contain a win-win option I see a huge 
potential of it doing more harm than good *to* Debian as a project. 
Cause without a win-win option the result of it will likely alienate 
some Debian contributors, developers, users away from Debian. You risk 
that either at least some Systemd supporters or at least some 
alternative init supporters would leave. And with a win-win option the 
GR may not be necessary.

[1] for example https://ungleich.ch who use Devuan for there datacenter 
infrastructure or for example Alpine Linux, which does not use Systemd.


Reply to: