Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, 18 Nov 2020 17:33:26 + Matthew Vernon wrote:
> This bug report relates specifically to bugs in the network-manager
> package (#921012, #964139) but has broader implications, particularly
> around what it means to "support the efforts of developers"[0] working
> on support for alternative init systems (I will talk about sysvinit here
> without loss of generality to other non-systemd init systems).
First, as a point of order (for which some authoritative guidance from
the Secretary, CCed, would potentially prove useful): while the
technical committee is empowered to handle various types of disputes (up
to and including overruling an individual developer if necessary), I do
not believe it falls within the scope of the technical committee to
override a decision already decided by a project-wide GR, or to
"interpret" the text of a GR issuing a nontechnical policy document in
ways that may undermine the decision made in that GR and document. Any
interpretation of the text of the GR would need to be based on the text
and intent of the GR. (Intent could include discussion at the time, but
would notably include the text of other options that did not prevail, as
well as the status quo at the time that motivated a GR to change.)
Changing that intent would require either another GR, or (per specific
provisions included in the winning GR option) consensus among the
project, not a TC ruling.
Concretely, the GR explicitly acted by "Using its power under
Constitution section 4.1 (5)", which is the power to "Issue, supersede
and withdraw nontechnical policy documents and statements.". The
Technical Committee does not have such "nontechnical policy documents
and statements" within its ambit. Any interpretation of 'what it means
to "support the efforts of developers" working on support for
alternative init systems' would thus be an interpretation of such a
nontechnical policy document.
Thus, I would suggest that the technical committee should decline to
rule on any matters already decided by the GR. This does not preclude
the TC from offering advice, or potentially facilitating dispute
resolution if asked to do so, or even as a *last resort* overruling a
developer on a specific technical matter (if doing so does not go
against the GR), but I don't believe it's within the scope of the TC to
relitigate the GR to mandate support for alternative init systems. Any
potential ruling here would need to avoid attempting to supersede the
GR.
That furthermore means that the question asked in the subject ("Should
maintainers ...") is much, much broader than any question that should be
ruled upon in this issue (if any). The GR answered a closely related
question, namely whether maintainers should be *forced* to accept
support for alternative init systems, with a definitive "no".
While the GR did explicitly state that the "position may evolve as time
passes without the need to resort to future general resolutions", that
provision would require project consensus in order to evolve such a
position. I don't think there's been any indication that consensus has
substantively changed in that regard since the time the project passed
that GR. In the absence of such consensus, the GR stands as the decision
of the project developers.
One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was,
in large part, to settle with finality many ongoing case-by-case
disputes about alternative init system support, and to allow developers
to work in peace without having to continuously deal with this disputes
of this type; in short, the goal (by proponents of many different
positions) was to settle init system questions in one direction or
another, in the hopes that the project would abide by the decision once
made, rather than expending ongoing energy and attention relitigating it
on a case-by-case basis.
The GR contained options for requiring ("must"), or even strongly
encouraging ("should"/"important"), developers to maintain sysvinit
support; those options did not win. The winning option, instead, issued
a policy statement that allowed continuing exploration and
experimentation with alternative init systems, but specifically stated
that "Those interested in exploring such alternatives need to provide
the necessary development and packaging resources to do that work.", and
furthermore left it to maintainer discretion ("may", not "should" or
"must") whether to include such support in packages. There were
certainly more than enough options on the table to allow the developers
by way of GR to issue a stronger statement, and the developers declined
to do so. And it's even more emphatically clear that "Further
Discussion" was not the desired outcome.
Per Debian Policy: "Guidelines denoted by may (or optional) are truly
optional and adherence is left to the maintainer’s discretion." Also see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948115 , which
implemented the GR in Debian Policy.
Any inclusion of work into a
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On 18.11.20 18:33, Matthew Vernon wrote: > Package: tech-ctte > Control: block 921012 by -1 > Control: block 964139 by -1 > X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk > > Dear Technical Committee, > > This bug report relates specifically to bugs in the network-manager > package (#921012, #964139) but has broader implications, particularly > around what it means to "support the efforts of developers"[0] working > on support for alternative init systems (I will talk about sysvinit here > without loss of generality to other non-systemd init systems). > > In brief: > > #921012 is about changing network-manager to Depend upon "default-logind > | logind" rather than libpam-systemd > > #964139 is about restoring the removed network-manager init script which > was removed from the package. There is no suggestion that the init > script was buggy > > 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. > > Both bugs have sat open for extended periods with no input from the > maintainer; so I prepared an NMU and uploaded it to DELAYED/14 as well > as making an MR on salsa[1]. > > The NMU was declined, on the basis that removing the init script was not > a mistake; I'm not aware of any rationale being provided beyond that for > refusing either patch. > > I'm afraid the effect of this is that the maintainers of this package > are making it impossible for other developers to enable support of > sysvinit. There are people[2] who will (and have) test compatibility > changes, help with issues with sysvinit scripts, and so on, but those > efforts are in effect being stonewalled. > > The effect of this, and equivalent behaviour in some other packages, is > that it is going to be impossible to make a useful Bullseye for users > who want to use sysvinit. > > I (and a couple of other interested parties) have approached the DPL > about this matter on a number of occasions this year, and have tried to > follow their advice where possible. I regret that it has proved > necessary to involve the technical committee. > > 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 > * Similar init-compatibility changes should not be blocked by package > maintainers unless they are defective on their own merits > * These changes be made in time to be effective in Bullseye I know it was mentioned back in the day, but trying to re-ask it now: Wouldn't it be possible to ship init scripts for compatibility purposes from a sysvinit (or maybe a sysvinit-support) package? This would be the inverse of what happened back when systemd was introduced, which was about shipping service files that superseded existing init scripts. I understand that you might not want that maintenance burden, however it seems like the network-manager maintainers might not want that maintenance burden either. That obviously would not solve the dependency issue, where the (not copied) claim of the maintainers is that there is no interface equality between what you suggest and what they think is appropriate. The last message in the bug suggested dropping a file in network-manager's config directory to disable a certain feature. With hooks it's clearly acceptable to drop files into configs of other packages and one could argue that a configuration directory is a similarly acceptable interface to reuse from another package. Maybe there'd be an amenable way if the interaction is properly defined? Like a support package doing that providing some pseudo-package that can serve as an alternative dependency. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon wrote: > > I invite the technical committee to rule that: What a great read! This message must be among the best prepared, and most polite, to come before the committee. Kind regards, Felix Lechner
Bug#971515: Status as of last tech-ctte meeting
Hello all, On Wed 18 Nov 2020 at 11:36AM -06, Gunnar Wolf wrote: > So... It's not like we reached a conclusion, but I do feel the meeting > was interesting and the discussion very much worthy. Yes, this will > surely end up in reinforcing the notion that the Technical Committee > is a slow and bureaucratic beast :-) But... well, I'll stop > apologizing. Only some minutes to go before the meeting, and I want to > give the rest of the Committee the opportunity to check if I didn't > misrepresent them or skip too much of their opinion. Thank you for this summary. At today's meeting one point which we thought was missing from this summary was that no-one on the committee has any appetite for overruling the package maintainer, so it is very unlikely that will be the outcome of this bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#971515: Status as of last tech-ctte meeting
Hello world, When we had our last tech-ctte meeting, 2020.10.21¹, I volunteered to write up a summary of our positions regarding this bug. Then... Well, life happened, and I have not had the time to sit down and write until today -- A couple of hours before our next meeting. Several other discussions have happened as well, most notably, the article by Jonathan Corbet on this issue in LWN². ¹ http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-10-21-17.58.html http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-10-21-17.58.log.html ² https://lwn.net/Articles/835599/ # Vendoring: Impedance mismatch with our long-established # practices/traditions ## I believe the issue of vendoring to be central to the discussion of what Debian is, and what its role should be. We are very lucky to have proponents of both sides of this issue in the Committee, and I'll try to keep my ideas as centered as possible (of course, disclaimer: I do hold a position, I really do not like vendoring; we have the luck of having Elana in the ctte, as she is a developer of the affected package, and Sean, who is a Debian Policy editor). Elana started off with a very important and true point: Elana> I think this bug was sort of inevitable. Debian policy cruft is clashing with how people actually build and distribute software these days. we have an appeal to override a maintainer on the basis of "policy" and the "Debian way being superior" without any real technical examination of the merits of "the Debian way" We are quite far from 1996, yes, and many languages have for a long time delivered their own packaging systems, "freeing" the users from the need of installing a myriad of little packages, and "freeing" the distribution caregivers (and I don't only mean the developers, but also the ftp-masters) and infrastructure from carrying this myriad of little packages. Elana and Sean seem to share the thought that each language ecosystem could work with somewhat different rules: Sean> It might be reasonable to vendor like mad for something written in Go but not for something written in Haskell, say Elana> Debian policy is specifically built around the distribution and execution of dynamically linked C/C++ applications and libraries. distros in general were. but modern software above that base does not necessarily operate under the same assumptions and it is silly to apply policy that was designed for applications that are dynamically linked against programs that are statically linked and are impossible to dynamically link Simon mentioned that "our identity should be about shipping high-quality packages, whatever that means", and mentioning that "our packaging policy is designed for medium-sized packages", refereed back to the discussions had long time ago over tiny Javascript snippets packaged as packages, back in the starting days of the nodejs growth. # DFSG-freeness checking ## Sean and I shared the concern that excessive vendoring (say, having tens to hundreds of libraries shipped as part of a single package) place a very heavy burden on our ftp-masters when checking DFSG-freeness; coupling this with the rapid change rate that "new-wave" software development usually has, if adding / dropping dependencies from already packaged software is usual practice, DFSG-checks would not just have to be made in NEW, but as a continuous process. Far from sustainable, and impossible to do by our ftp-master team practices. # Security issues ### The issue of security support was also mentioned: If many packages start shipping tens or hundreds of vendored libraries, how can we ensure security support? This has long been a pride point for Debian and, in general, for the Linux distributions model. We package independent libraries, dynamically link them, and security supports "just happens" for the users. Now, what happens in languages as Go or Rust, where linking is done statically? They would have to be at least recompiled when any of their constitutive libraries is updated. But what if the libraries are vendored-in? Security issues are prone to be hidden from our sight. I'm pasting here a bit of the discussion that happened later during the meeting: having this discussion K8S-specific, Elana mentioned that "that is a big part of the tension. sometimes, you have an upstream where the authors are less resourced and responsive than the downstream. this case is almost certainly the opposite". At this point, we found some friction as to _what_ we are discussing on: Is this bug specifically on Kubernetes, which should be taken as a special case? Or would we try to rule as the Technical Committee on vendoring in general in the Debian ecosystem? Elana repeated her assurance that the Kubernetes team is thorough in their freeness-checking and security practices; I insisted on "not discussing about K8S, but about a bundling practice to which K8S
