Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, 18 Nov 2020 at 17:33:26 +0000, Matthew Vernon wrote:
> #921012 is about changing network-manager to Depend upon "default-logind |
> logind" rather than libpam-systemd
This is a change that is *sometimes* appropriate, but sometimes not,
depending on what facility the dependent package intends to receive
from the dependency. It needs to be assessed on a case-by-case basis,
and cannot be done mechanically across the distribution.
default-logind | logind is appropriate if the package's needs are
limited to "something that looks sufficiently similar to systemd-logind"
(like for example policykit-1, where I applied exactly that change),
but is not appropriate if it needs other systemd-specific facilities
(like for example dbus-user-session, which currently needs a working
`systemd --user` and has no way to function correctly otherwise).
I haven't fully investigated what facilities NM requires from
systemd. According to #921012 it requires hostnamed in its default
configuration, and according to the Gentoo wiki it expects to see
/etc/machine-id for DHCPv6. There might be others.
> #964139 is about restoring the removed network-manager init script which was
> removed from the package.
There's some good discussion about this elsewhere in the thread, in
particular around putting init-system integration in a place where the
maintenance responsibility and effort rests with those who are interested
in supporting the relevant init system.
I think we have three options:
* overrule the NM maintainer on both #921012 (logind dependency) and
#964139 (init script inclusion) as you ask;
* decline to overrule the NM maintainer on either point;
* overrule the NM maintainer on #921012 but do not overrule on #964139, and
instead expect the init script to be provided by some other package that
is maintained by people who are interested in non-systemd init systems
I don't think it would make any sense to overrule on #964139 but
not on #921012, because if NM depends on libpam-systemd (which
requires/assumes systemd as pid 1), then people who want to use non-default
init systems will remain equally unable to use NM. Do you agree?
If NM is only compatible with non-systemd init systems when
placed in a non-default configuration, then it might make sense
for it to have a dependency on something like
"systemd-sysv | initscripts-network-manager", where
initscripts-network-manager provides an LSB init script and
also provides configuration fragments that configure NM
in a non-default way that does not require systemd (for example providing
the configuration fragment mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921012#72).
> Both changes are necessary for it to be possible to install network-manager
> on a sysvinit system; it is going to be hard to use Debian without
> network-manager.
It's a popular package, but to put this in perspective, this is the same
network-manager for which a previous technical committee overruled the
GNOME maintainers to require that the GNOME metapackages must not have
a hard dependency on it. Now, a lot can change in 8 years, but even so
it seems like a stretch to argue that Debian is sufficiently hard to
use without NM that having non-default init systems exclude use of NM
is necessarily a showstopper for the ability to experiment with those
non-default init systems?
We can't expect non-default init systems to be as closely integrated as
the default, and diverging from defaults is always going to involve some
compromises and reconfiguration, particularly defaults that are low down
in the dependency stack.
Alternatives include at least connman, wicd (not in testing because it
requires Python 2, but I'm sure interested developers could constructively
help to push it forward), and ifupdown. (Also systemd-networkd, but that
expects systemd as pid 1, and given its upstream maintenance model it
would seem unreasonable to expect a downstream maintainer to change that.)
smcv
Reply to: