Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Mon, 30 Nov 2020 10:55:44 + Mark Hindley wrote: > On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote: > > On Wed, 18 Nov 2020 at 17:33:26 +, 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.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On 29/11/2020 16:59, Simon McVittie wrote: Some procedural points, without going into the merits of the technical committee doing as you ask or not: Broadly, I expect the TC to know their procedural stuff better than I do, but I'll try and answer your points :) On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: I invite the technical committee to rule that: * The network-manager init script should be restored * Network-manager should Depend: on default-logind | logind rather than libpam-systemd This looks like a request to use the technical committee's power to overrule the maintainer of network-manager under section 6.1.4 of the Debian constitution. Is that what you are asking for? Yes, I think so; I mean, you might also decide that this is a matter where jurisdictions overlap (between the init diversity folk and the network-manager maintainers), and I wouldn't think that unreasonable. * Similar init-compatibility changes should not be blocked by package maintainers unless they are defective on their own merits This seems like a broader request, and it's less clear which of the technical committee's powers you are asking us to use. Please could you either clarify what you are asking us to do, or reduce the scope of this request to the issue that you are immediately concerned with, namely network-manager? I'm not going to answer this directly, but instead try and explain what I was hoping to achieve - as you say (in text I've snipped), there are a number of ways you might wish to address this question. Let us beg the question for the moment, and suppose you agree with me that the changes I outline should be made to network-manager. Suppose further that there are other packages where fundamentally the same question arises between now and the bullseye freeze (this isn't a hypothetical; there are). I would suggest that it's not in anyone's interests for each bug report to have to come before the TC in turn (I think this is obviously true, but can justify this if you like). To that end, you might want to say something about the more general case at least in period leading to the bullseye release, whether that's expressed as deciding a matter of policy or giving advice. If that's a longer decision-making process, I don't see why you couldn't say "The TC rules on the request to overrule thus; and will say more on the matter hereafter" and then say something more general later. I don't think any statement of this kind would be overriding the GR - as I said in my initial bug report, I think the GR supports what I'm trying to achieve here (pace Josh). To briefly address the question on network-managers utility raised elsewhere: I think it is true both that there are many systems where it is roughly essential (portable devices - nothing else comes close from a managing multiple networks POV), and also classes of systems where being able to install GNOME without it is clearly desirable (desktop systems with complex but stable networking where ifupdown or netplan are more appropriate). Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Simon, Thanks for your clear and insightful comments. On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote: > On Wed, 18 Nov 2020 at 17:33:26 +, 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
