Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Mark Hindley <mark@hindley.org.uk>]

Simon,

Thanks for your clear and insightful comments.

On Sun, Nov 29, 2020 at 11:58:15PM +0000, Simon McVittie wrote:
> 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.

In my testing, network-manager works without issue using libpam-elogind. It does
not require 'systemd -- user' and falls back to legacy implementations if
hostnamed is not available.

> 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?

I agree fully. However I would also propose the inverse logic: #921012 appears
to be resolvable in that NM works with elogind without problems and exploration
of alternative technologies such as elogind was explicitly included in the
winning GR option. But to overrule #921012 but not #964139 would also make
people who want to use non-default init systems still equally unable to use NM.

Thanks.

Mark