Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On 15/12/2020 22:07, Sam Hartman wrote:
However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features. Those interested in exploring such alternatives need to
provide the necessary development and packaging resources to do that
work. Technologies such as elogind that facilitate exploring
alternatives while running software that depends on some systemd
interfaces remain important to Debian. It is important that the
project support the efforts of developers working on such technologies
where there is overlap between these technologies and the rest of the
project, for example by reviewing patches and participating in
discussions in a timely manner.
We did not say in that GR that we were interested in supporting ongoing
development of sysvinit.
I find it surprising that, in a TC bug about (inter alia) whether a
dependency on libpam-systemd should be changed to default-logind |
logind i.e. to facilitate use of elogind you appear to be saying that a
GR text that talks about the importance of "technologies such as
elogind" should be interpreted as meaning in effect that actually it
isn't all that important and network-manager should continue to have
effectively a systemd-only dependency.
Not is it straightforwardly clear that "alternative init systems" should
in fact be interpreted to mean "alternative init systems (but not
Nor is this a case of someone demanding that the network-manager
maintainer provide a sysvinit script nor fix the bugs in an
By analogy, consider a Finnish translation for a package - as a
maintainer I don't know enough Finnish to write nor usefully evaluate a
particular translation; but I apply it to my package if one is supplied.
If it's erroneous enough that bug reports pile up about it and no-one
supplies a fix, I might eventually pull it from the package. But some of
the arguments in this thread seem quite close to "non-systemd users
might have a slightly less good experience with network-manager, so we
should prevent them from using it at all" - which would be like me
deciding that my Finnish users might get slightly imperfect messages so
I shouldn't support that language at all.