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