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

[Josh Triplett <josh@joshtriplett.org>]

On Mon, 30 Nov 2020 10:55:44 +0000 Mark Hindley <mark@hindley.org.uk> wrote:
> 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.

Which would then make those legacy fallbacks load-bearing, when they
previously were not. If (hypothetically) network-manager upstream
decided to remove those legacy fallbacks, the maintainer would then be
in a position of either:

1) not noticing, and having users experience breakage that could have
been foreseen, in addition to one of the following two options,

2) changing the dependency accordingly to reflect the new hard
requirement on hostnamed, and potentially finding themselves hauled in
front of the TC *yet again*, or

3) maintaining a downstream patch forever. This would, again, put
someone in the position of having to maintain support for alternative
init systems, which the GR does not require any maintainer to do. And
keep in mind that rebasing patches for new upstream versions isn't
typically work that can be offloaded, even if someone were willing to do
so; the nature of such work is that it typically has to be done all at
once.

This would be a much more reasonable request if the alternative
implementations provided a version of hostnamed (and anything else
network-manager relies on), such that network-manager could
transparently rely on such functionality without having to implement a
fallback itself. With the fallback code provided within the alternative
implementations themselves, that would ensure that any bug reports on
that fallback code would *also* be the responsibility of the alternative
implementations.

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

Only until, as observed in the mail you're replying to, someone
interested in an alternative init system implements a solution for:
> 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.