Re: Integration with systemd
Hi!
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
system.
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
anyway.
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
started.
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
hindrance.
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.
Thanks,
--
Martin
Reply to: