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
