Bug#975075: marked as done (tech-ctte: Should NetworkManager support elogind?)

[Debian Bug Tracking System]

Your message dated Wed, 17 Mar 2021 18:03:09 +0100
with message-id 
and subject line Closing as this has been resolved without the TC needing to 
intervene
has caused the Debian Bug report #975075,
regarding tech-ctte: Should NetworkManager support elogind?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

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

Regards,

Matthew

[0] From the wording of the winning option in the 2019 Init systems GR
[1] https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/7
[2] e.g the mailing list debian-init-divers...@chiark.greenend.org.uk of 
people who are more than happy to help with this sort of thing
--- End Message ---
--- Begin Message ---

Hi,

It's been a while since this bug was dealt with and I was tasked with 
closing

it, I'm sorry that it took so long to write this reply.

The technical committee declines to overrule the NetworkManager and 
udisks2

maintainer on this matter.

Instead, by working together with the maintainer of the affected 
packages, we
managed to achieve a compromise solution: the dependency on 
libpam-systemd was
lowered to a recommends so that it's still possible to install the 
package
without it, while a separate package was introduced to carry the removed 
init

scripts.

This compromise solution allows users of other init systems to still use
network-manager and udisks2, without imposing additional work on the 
maintainer

to support those other systems.

As has been mentioned in the bug, this compromise was achieved through 
private
discussions between the technical committee and the maintainer. We 
recognize

that these kind of private discussions are not ideal and can lead to
frustration on the side of those that just hear about the results of the
discussions without being able to participate in them. On the other 
hand, we
also recognize that some maintainers have been burned out by some 
particularly

contentious issues, and would rather not discuss them publicly.

In the general case, the Technical Committee urges u

Bug#975075: Closing as this has been resolved without the TC needing to intervene

[Margarita Manterola]

Hi,

It's been a while since this bug was dealt with and I was tasked with 
closing

it, I'm sorry that it took so long to write this reply.

The technical committee declines to overrule the NetworkManager and 
udisks2

maintainer on this matter.

Instead, by working together with the maintainer of the affected 
packages, we
managed to achieve a compromise solution: the dependency on 
libpam-systemd was
lowered to a recommends so that it's still possible to install the 
package
without it, while a separate package was introduced to carry the removed 
init

scripts.

This compromise solution allows users of other init systems to still use
network-manager and udisks2, without imposing additional work on the 
maintainer

to support those other systems.

As has been mentioned in the bug, this compromise was achieved through 
private
discussions between the technical committee and the maintainer. We 
recognize

that these kind of private discussions are not ideal and can lead to
frustration on the side of those that just hear about the results of the
discussions without being able to participate in them. On the other 
hand, we
also recognize that some maintainers have been burned out by some 
particularly

contentious issues, and would rather not discuss them publicly.

In the general case, the Technical Committee urges users and maintainers 
to

communicate openly and try to find compromise solutions like this one.

Thanks,
Marga on behalf of the Technical Committee

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

[Jan Korbel]

Dear Debian developers, maintainers etc.

I use Debian for many years. My primary and only installation for work
is unstable installed in 2003 and i updated this one *many times*. I
love Debian because of freedom from more points of view.

One PoV is possibility to choose software component which i prefer.
Because i don't like systemd (other story) i use sysvinit not on my
computer only but on many our servers too. My fault is, they are
without popcon, so not in stats (will fix it, i promise).

When i read about maintainer which broke thing (on my system too) and
rejected fix because... i still don't know why, i feel very sad. I
don't think this is a fair community work which is great otherwise.

So thanks Matthew and others they did not throw us overboard. I use
orphan-sysvinit-scripts now. Not best solution imho, but it is others
fault. Shame.

Sorry for some emotions and peace.

Regards,

J.

Bug#975075: analogies

[Simon McVittie]

Sorry for the delay in responding to this, but I wanted to wait until
the technical question before the committee had arrived at a result
before replying to it.

On Thu, 19 Nov 2020 at 06:49:37 -0800, Felix Lechner wrote:
> In Debian, users of 'sysvinit' strike me as such a "disfavored class".

This sounds as though you're saying that Debian maintainers making
technical decisions about the packages they maintain, affecting people
who have chosen to use or contribute to Debian, are ethically or morally
equivalent to a government whose citizens have little or no choice whose
jurisdiction they live under, making laws that discriminate or persecute
on the basis of characteristics like sexuality.

I don't think that's a reasonable analogy to make, and I suspect that
members of genuinely persecuted groups would feel that it's trivializing
their situation.

I hope that wasn't your intention, but please be careful about analogies
that relate to sensitive topics.

smcv

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Sam Hartman]

General arguments about how the TC should conduct its business do not
belong on this bug.
I'd appreciate it if replies to this message are directed to a different
place than this bug.

We've established that the TC is operating consistently both with its
historical process and with currently permitted behavior for a group of
Debian developers.
You're making an argument about what the TC's behavior should be that is
general, not specific to this issue.

Please make that argument in a general forum and do not tie it to this
issue.

You're also making an argument that has been made before without
choosing to avail yourself of the history of the discussion on TC
privacy.
My recommendation would be to find someone who agrees with you who has
followed that history and learn it--at least the parts of the history
that support your position.
Your argument would come across stronger if you did.

> "Felix" == Felix Lechner  writes:

Felix> Hi,
Felix> On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
>> 
>> the ability to talk privately with the committee is something
>> CTTE has allowed for a long time

Felix> Debian has many great traditions, but the Magna Carta is much
Felix> older. I found a great article about it ([1], p. 5):

Felix> "the simple human need for fairness, reflected in western
Felix> jurisprudence since at least 1215 when it was pronounced in
Felix> the Magna Carta, underlies the legal concerns about ex parte
Felix> communications during administrative decisionmaking
Felix> processes. Fairness certainly requires an impartial
Felix> decisionmaker, and often the appearance of impartiality can
Felix> become as important a factor in the legal review of fairness
Felix> as actual impartiality."

Fortunately for all of us, the TC is not a legal body, and this is not a
legal dispute process, nor does jurisprudence apply as a concept.

Yes, you can consider whether concepts from jurisprudence should wrap
over to Debian processes, but you need to actually justify that, and
consider the trade offs.
It is unsurprising to me that the trade offs for a legal process that
can deprive someone of property and life work out differently than the
trade offs for a body charged with choosing a technical path for an
operating system.
That's true even when people are emotionally invested in the outcomes.
Fairness is one thing that someone might value.
It tends to be highly valued in jurisprudence, but other things might be
valued more highly in a proceeding like the TC.
And you don't get fairness when the process is emotionally draining
enough that key stakeholders refuse to cooperate.

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Felix Lechner]

Hi,

On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
>
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time

Debian has many great traditions, but the Magna Carta is much older. I
found a great article about it ([1], p. 5):

"the simple human need for fairness, reflected in western
jurisprudence since at least 1215 when it was pronounced in the Magna
Carta, underlies the legal concerns about ex parte communications
during administrative decisionmaking processes. Fairness certainly
requires an impartial decisionmaker, and often the appearance of
impartiality can become as important a factor in the legal review of
fairness as actual impartiality."

The State of Hawai'i publishes a simpler guidance prohibiting private
communications with a judge. [2]

Kind regards
Felix Lechner

[1] 
https://www.cacities.org/Resources-Documents/Member-Engagement/Professional-Departments/City-Attorneys/Library/2016/Annual-2016/10-2016-Annual_Calonne_Lets-Ex-Parte!-The-Limits-a.aspx
[2] https://www.courts.state.hi.us/self-help/exparte/ex_parte_contact

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Gunnar Wolf]

Sandro Tosi dijo [Tue, Jan 26, 2021 at 08:47:22PM -0500]:
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time; it's a two-sided coin: it can prevent heated
> exchanges, but it can also leave a sour taste in the petitioner's
> mouth.
> 
> While i would tend to agree that it's slightly unfair, i've never been
> on the other side to judge it fully.

While we discussed the 2016/002¹ and 2016/004² GRs, about the
declassification of debian/private, we discussed the argument that any
group of people (and, certainly, any group of Debian developers) could
set up a private communication channel.

  ¹ https://www.debian.org/vote/2016/vote_002
  ² https://www.debian.org/vote/2016/vote_004

We do, yes, maintain some private communication while working
officially as the Technical Committee - and it's a known fact. We try
to maintain as little as possible contact with maintainers that are
part of a dispute... But sometimes, it's the only way to move
forward.

We have to acknowledge not all DDs have the same personal
skills. Disputes are draining for everybody, but some people might
find it even harder. Engaging directly with a person with whom you
already have a story of tension is something mnay people will do their
best to avoid.

So, yes, sometimes we will use private communications, and try to
serve as a channel between the parts through which the essence of the
communication, without the thorns and the pain, can better flow.

Of course, there is a committment that we will share the fact this
communication took place, and we will communicate the contents to the
community at large.


signature.asc
Description: PGP signature

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Felix Lechner]

Hi,

Sorry to comment so late. A meeting about this bug may already be in progress.

On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon  wrote:
>
> The maintainer won't talk to me, nor will they engage with me (or anyone
> else) on this thread, though they will it seems talk to the TC in private.

In most places, a failure to respond would result in a default
judgment for the aggrieved party—in this case Matthew.

Here, the situation here is more complicated. There was a private
communication with the committee, but such side conversations are
unfair: How can Matthew ever feel that justice was served? I would
personally not feel closure unless I saw all such communications and
had an opportunity to respond.

Secrecy, if it is really needed, should instead be implemented by
requiring all parties involved to keep sealed records confidential.

I urge the committee to please reconsider its willingness to engage
with one party without the other present. The dignity of the Technical
Committee—Debian's highest and most hallowed body—could suffer.

Thank you!

Kind regards
Felix Lechner

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Sam Hartman]

> "Russ" == Russ Allbery  writes:


>> I have not come to the TC to ask them to overrule the maintainer
>> frivolously nor before exploring as many other options as I
>> could.

Russ> I understand (oh, boy, do I ever) how strained relationships
Russ> are after the long-running init system battles, but it's very
Russ> hard to resolve problems without the TC when one of the
Russ> parties is unwilling to communicate.  There have been a lot of
Russ> other hostile and aggressive threads about init system issues,
Russ> but this specific bug is not one of them as far as I can tell.

Russ> I don't want to force anyone into communicating when they
Russ> don't want to (general rule 2.1.1), but then I think they need
Russ> to welcome NMUs or a co-maintainer who can deal with the
Russ> things they don't want to have to think about or *something*.
Russ> This kind of silent treatment is really demoralizing to other
Russ> people in the project who are not at fault for any of the
Russ> historical init system hostility.

I'd like to second Russ's analysis here.  I was DPL during a chunk of
the relevant time, and was not able to get communication happening even
when relevant parties (Mark in particular) were being constructive.

I totally understand being burned out on the issue of init systems.
I totally understand being a maintainer who doesn't want to deal with
that.
I think the solution Russ proposes is right in that situation: find
someone you trust to NMU or act as a co-maintainer to move things
forward.

I think it is entirely reasonable for the TC to consider factors like
whether a maintainer is  willing to do that.

Yeah, it sucks when we override a maintainer.
Yes, that's demotivating.

So is creating a situation where people who are being constructive
cannot even engage.
It's one thing to engage with a maintainer and have them consider your
arguments and disagree.
It's another thing entirely when people are trying to work
constructively within the spirit of a GR that we as a community passed
and cannot even get their contributions considered.

That drives people away and  discourages Debian from growing.
I don't think we want that culture.


signature.asc
Description: PGP signature

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Matthew Vernon]

On 17/01/2021 10:29, Andreas Henriksson wrote:


Possibly getting off topic here, but I happened to read a bit of this
discussion and while seeing your comment I thought it might be a good
time to remind you about #934463.


I agree it's off-topic here, so I've sent a message to that bug 
suggesting an approach.


Regards,

Matthew

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Andreas Henriksson]

Hello Matthew Vernon,

On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote:
> [...], and while I hope your ruling will not result in a bonfire of
> perfectly good init scripts, I hope that maintainers who decide to
> ditch them will let us know so we can add them there
[...]

Possibly getting off topic here, but I happened to read a bit of this
discussion and while seeing your comment I thought it might be a good
time to remind you about #934463.

While I'm no longer maintaining the relevant package, I don't think
you should expect the current situation to persist for as many years
as we've already been carrying this for you. You have been let known,
so please spare us from receiving rage once it actually happens.

(I'd personally also be very happy if we could see some movement on
a bunch of other sysvinit bug reports that is relevant even for
non-sysvinit users, which would at the same time give me more confidence
in that it's useful to engage in discussion like this at all.)

Regards,
Andreas Henriksson

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Russ Allbery]

Matthew Vernon  writes:

> The maintainer won't talk to me, nor will they engage with me (or anyone
> else) on this thread, though they will it seems talk to the TC in
> private.

> I think, though, that it is common ground between submitter and
> maintainer that the Depends is necessary for udisks2 (unlike in
> network-manager where it turned out not to be).

> There was some discussion about whether elogind works with udisks2 in
> early 2019 and again in early 2020. On 2020-03-15 Nils draws the
> maintainer's attention to the explicit mention of elogind support in
> udisks upstream changelog.

Looking at this bug, I agree with Matthew: there is no indication that I
can see in the bug discussion that the solution proposed there would not
work.  I can speculate about why the maintainer may have not wanted to
change the dependency, but it's somewhat pointless to do so in the absence
of any additional information.

There may be some Policy work necessary to make it clear that this
dependency can also be used for packages that use the C ABI, not just the
D-Bus ABI, but I don't see any clear reason why that should block this
change.

If the question is one of maintainer support, adding some note in
README.Debian or in a reportbug prescript to say that only systemd is
directly supported by the package maintainer and problems on non-systemd
systems will require someone else to step forward to analyze and help with
the problem feels like a better solution for the project as a whole than
not changing the dependency.

> I have not come to the TC to ask them to overrule the maintainer
> frivolously nor before exploring as many other options as I could.

I understand (oh, boy, do I ever) how strained relationships are after the
long-running init system battles, but it's very hard to resolve problems
without the TC when one of the parties is unwilling to communicate.  There
have been a lot of other hostile and aggressive threads about init system
issues, but this specific bug is not one of them as far as I can tell.

I don't want to force anyone into communicating when they don't want to
(general rule 2.1.1), but then I think they need to welcome NMUs or a
co-maintainer who can deal with the things they don't want to have to
think about or *something*.  This kind of silent treatment is really
demoralizing to other people in the project who are not at fault for any
of the historical init system hostility.

-- 
Russ Allbery (r...@debian.org)  

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Matthew Vernon]

On 16/01/2021 01:39, Gunnar Wolf wrote:

Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:



Please overrule the maintainer in #923387 so that it is can be used on
systems with elogind; it has been tested and shown to work thus as well as
being supported by upstream[1].


As it was mentioned on a previous mail to this thread, this discussion
on including an elogind dependency was done WRT network-manager. An
agreeable solution was brought forward by the maintainer. #923387
(udisks2) was just mentioned in this discussion. Maybe an amicable
solution can be tried before asking the TC outright to overrule the
maintainer?


The maintainer won't talk to me, nor will they engage with me (or anyone 
else) on this thread, though they will it seems talk to the TC in private.


I think, though, that it is common ground between submitter and 
maintainer that the Depends is necessary for udisks2 (unlike in 
network-manager where it turned out not to be).


There was some discussion about whether elogind works with udisks2 in 
early 2019 and again in early 2020. On 2020-03-15 Nils draws the 
maintainer's attention to the explicit mention of elogind support in 
udisks upstream changelog.


Later that day, the maintainer closed and archived(!) the bug, for 
reasons they decline to elaborate on.


Mark reopened on 2020-07-02 on the basis that the bug isn't fixed.

Adam sent a ping on 2020-12-31, reminding the maintainer that udisks2 is 
important for a range of desktop software, that the freeze is coming, 
and that udisks2 works with elogind, and asking them again to apply the 
(trivial) patch.


There has been no input from the maintainer of this package for over 9 
months.



Mark tells us that there are not currently any other packages which could be
used with elogind were it not for an incorrect dependency on libpam-systemd,
so I hope we don't need to worry about the broader question any further.


Given the arguments are prone to be very similar, and the issue itself
will unfold in a similar fashion, can we try to have a different
process? One that does not bring so much heat? I hope a very similar
resolution can be had for #923387 - without needing a six-week-long discussion.


I don't think this bug can be resolved by downgrading the Depends: to a 
Recommends:. The maintainer may be able to correct me on that point.


We are getting very close to the freeze; without this fix it will be 
impossible to install a range of desktop software on a bullseye system 
that runs any init system other than systemd.


The maintainer may not like elogind, but udisks supports elogind, and 
the project resolved that technologies like elogind that enabled 
alternative init systems were important to the project.


I have not come to the TC to ask them to overrule the maintainer 
frivolously nor before exploring as many other options as I could. The 
TC is Debian's body for resolving issues of this sort, and the 
maintainer will at least talk to you. Naturally, if you can persuade 
them to fix 923387 in a way that means we can use udisks and elogind 
together in Debian in bullseye I would be delighted. But otherwise, I 
think you must overrule them, and soon enough that they can upload a fix 
so it gets into bullseye.


Regards,

Matthew

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Gunnar Wolf]

Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:
> > If you intend the scope of this bug to involve overruling maintainers'
> > decisions in packages other than NM, what other packages/bugs did you
> > have in mind? Is it just udisks2/#923387, or are there more?
> 
> I understand (but I don't think it has been explicitly stated) that the TC
> is going to decline to overrule on the question of init scripts?[0] I'm
> going to beg that question for the rest of this mail, but obviously if I'm
> wrong that will increase the scope somewhat.

I cannot say we will always decline to overrule. But -talking just for
myself, not for the whole TC- overruling a maintainer on
_anything_ is something that I really really really prefer not to
do. I understand the TC is summoned often as a last-resort decision
making body. But forcing a maintainer to do something they are against
in their own package is too harsh -- And demotivating. A maintainer
forced to go against their best decision on an a matter important to
them (otherwise the issue would not get to the TC) is very much more
likely to lose interest in keeping up the maintenance, or even their
participation in the project. 

> Please overrule the maintainer in #923387 so that it is can be used on
> systems with elogind; it has been tested and shown to work thus as well as
> being supported by upstream[1].

As it was mentioned on a previous mail to this thread, this discussion
on including an elogind dependency was done WRT network-manager. An
agreeable solution was brought forward by the maintainer. #923387
(udisks2) was just mentioned in this discussion. Maybe an amicable
solution can be tried before asking the TC outright to overrule the
maintainer?

> Mark tells us that there are not currently any other packages which could be
> used with elogind were it not for an incorrect dependency on libpam-systemd,
> so I hope we don't need to worry about the broader question any further.

Given the arguments are prone to be very similar, and the issue itself
will unfold in a similar fashion, can we try to have a different
process? One that does not bring so much heat? I hope a very similar
resolution can be had for #923387 - without needing a six-week-long discussion.

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Sean Whitton]

Hello,

On Tue 12 Jan 2021 at 01:53PM +02, Wouter Verhelst wrote:

> Maybe talk to debian-policy to come up with some wording to be added to
> either the developer's reference or policy that discourages dropping
> init scripts, but encourages talking to the maintainers of
> orphan-sysvinit-scripts if for whatever reason it ends up being
> necessary?

Once the package has cleared NEW, we should definitely mention it in
Policy; whether we say anything to discourage dropping init scripts is
trickier however.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Matthew Vernon]

Hi,

On 10/01/2021 20:03, Simon McVittie wrote:


If you intend the scope of this bug to involve overruling maintainers'
decisions in packages other than NM, what other packages/bugs did you
have in mind? Is it just udisks2/#923387, or are there more?


I understand (but I don't think it has been explicitly stated) that the 
TC is going to decline to overrule on the question of init scripts?[0] 
I'm going to beg that question for the rest of this mail, but obviously 
if I'm wrong that will increase the scope somewhat.


Please overrule the maintainer in #923387 so that it is can be used on 
systems with elogind; it has been tested and shown to work thus as well 
as being supported by upstream[1].


Mark tells us that there are not currently any other packages which 
could be used with elogind were it not for an incorrect dependency on 
libpam-systemd, so I hope we don't need to worry about the broader 
question any further.


Regards,

Matthew

[0] to that end, orphan-sysvinit-scripts is in NEW, and while I hope 
your ruling will not result in a bonfire of perfectly good init scripts, 
I hope that maintainers who decide to ditch them will let us know so we 
can add them there
[1] I've not restated my rationale about how technologies like elogind 
are important to the project per GR etc etc. I can if you like, but I 
don't think that's necessary here

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Mark Hindley]

Simon,

On Sun, Jan 10, 2021 at 08:03:18PM +, Simon McVittie wrote:
> I wouldn't want to give a ruling that would be interpreted as precedent to
> (effectively) overrule multiple maintainer decisions (whether they're
> decisions by a single maintainer in multiple packages, or multiple
> maintainers' decisions in multiple packages) without at least being aware
> of how many packages and decisions we are affecting - similar to the
> principle that when the Policy editors add a new normative requirement,
> they usually want to know how many packages were compliant with the old
> Policy but are considered non-compliant under the new Policy.

[...]

> However, I think we would be reluctant to give a general ruling like that,
> because it would not always be correct. systemd is quite featureful and
> its interface is quite large (if I understand correctly, this is one of
> the major things that people who would prefer a different init system
> dislike about it). Different packages use different subsets of that
> interface, sometimes larger[1] than the subset that can be provided by
> elogind (because elogind closely resembles systemd-logind, and by design
> the other parts of systemd's interface are outside its scope). The extent
> to which the various parts of the interface are required by the dependent
> package (whether they would be Depends, Recommends, Suggests or nothing,
> if they were represented by separate dependencies) also varies.
> 
> dbus-user-session is one concrete example of a package that needs a
> working `systemd --user` instance per uid (a per-uid user-service
> manager), and so will not do what its (informal) specification
> says if it is forced to be installed on non-systemd systems -
> so replacing its libpam-systemd dependency with
> "default-logind | logind" would be incorrect. If that dependency
> was replaced, the replacement would have to include something like
> "libpam-systemd | libpam-start-dbus-daemon-per-uid", where the latter
> doesn't currently exist.

Of course you are quite correct that libpam-systemd provides access to 'systemd
--user' which libpam-elogind does not and can not.

In unstable the list of packages with a hard libpam-systemd dependency is now
quite small. Both dbus-user-session (as you say) and gdm3 require 'systemd
--user' and support for elogind has quite rightly been refused by the
maintainers on that basis. nix-setup-systemd is clearly systemd dependent. 2
packages are empty metapackages[1] with specific purpose that I would not expect
to support elogind. That leaves udisks2 and network-manager as the only
outstanding packages in which elogind support is possible but unavailable.

As in the case of network-manager, I can confirm that my testing of udisks2
shows it works with libpam-elogind without issue.

Obviously Michael is maintainer of both pacakges. In the absence of public
comment or engagement from him I do not want to infer his motives. However, the
end of his submission to the tech-ctte relayed by Elana states

> On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote:

[...]
 
> elogind is very difficult to support in its current state (see the
> following bugs: [2] [3] [4] [5]), which is why Michael does not want to
> maintain support for it.

I have already made the point that[2] the bugs he referenced have been addressed
and do not represent a technical reason why elogind should not be supported.

I completely understand that the tech-ctte would not want to make a ruling that
could be over generalised. But I don't think that is what is being asked for
(although Matthew may want to clarify this). This is about securing
implementation of the GR result. If there is a technical reason which prevents a
package working with elogind I completely agree that it would be wrong for it to
make use of the logind virtual packages.

Mark

[1]  progress-linux-base-system and debian-cloud-images-packages

[2]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#224

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Simon McVittie]

On Sat, 02 Jan 2021 at 18:36:23 +, Matthew Vernon wrote:
> While [lowering NM's dependency on libpam-systemd from Depends to
> Recommends] does address the co-installability of network-manager with
> elogind, I would like you to still say something officially about the issue,
> please, since this is not the only affected package.
> 
> As an example, bug 923387 (which Michael is also maintainer of) for udisks2,
> where the dependency must be a Depends not a Recommends (so the workaround
> used for network-manager won't help).

If you intend the scope of this bug to involve overruling maintainers'
decisions in packages other than NM, what other packages/bugs did you
have in mind? Is it just udisks2/#923387, or are there more?

Speaking only for myself as an individual TC member, rather than speaking
for the whole TC, but I suspect others feel similarly:

I wouldn't want to give a ruling that would be interpreted as precedent to
(effectively) overrule multiple maintainer decisions (whether they're
decisions by a single maintainer in multiple packages, or multiple
maintainers' decisions in multiple packages) without at least being aware
of how many packages and decisions we are affecting - similar to the
principle that when the Policy editors add a new normative requirement,
they usually want to know how many packages were compliant with the old
Policy but are considered non-compliant under the new Policy.

>From the original request, it seemed to me that network-manager was
considerably more important to you than other packages with systemd
dependencies, and so you were prioritizing a request to overrule that
particular maintainer decision, so we focused on network-manager. I'm
sorry if that was a misinterpretation.

Perhaps you were hoping we would give you a very general ruling like
"dependencies on libpam-systemd (must|should) always be replaced by
default-logind | logind" that is immediately applicable to all the
other packages you are interested in, and would have an effect similar
to overruling decisions in the other affected packages too, without us
having to specifically vote (with a 3:1 supermajority) to do so.

However, I think we would be reluctant to give a general ruling like that,
because it would not always be correct. systemd is quite featureful and
its interface is quite large (if I understand correctly, this is one of
the major things that people who would prefer a different init system
dislike about it). Different packages use different subsets of that
interface, sometimes larger[1] than the subset that can be provided by
elogind (because elogind closely resembles systemd-logind, and by design
the other parts of systemd's interface are outside its scope). The extent
to which the various parts of the interface are required by the dependent
package (whether they would be Depends, Recommends, Suggests or nothing,
if they were represented by separate dependencies) also varies.

dbus-user-session is one concrete example of a package that needs a
working `systemd --user` instance per uid (a per-uid user-service
manager), and so will not do what its (informal) specification
says if it is forced to be installed on non-systemd systems -
so replacing its libpam-systemd dependency with
"default-logind | logind" would be incorrect. If that dependency
was replaced, the replacement would have to include something like
"libpam-systemd | libpam-start-dbus-daemon-per-uid", where the latter
doesn't currently exist.

smcv

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

[Matthew Vernon]

Hi,

I see that network-manager 1.28.0-2 has been uploaded, with (inter alia) 
the following changelog entry:


* Demote libpam-systemd to Recommends.
 This allows users to use and experiment with other init systems. Such a
 setup is neither tested nor fully supported and users need to be aware
 that some functionality might be broken. (Closes: #921012)

I don't know if Michael has discussed this with you in private, and that 
you thus know why this change was made (rather than adjusting the 
dependency as requested).


While this does address the co-installability of network-manager with 
elogind, I would like you to still say something officially about the 
issue, please, since this is not the only affected package.


As an example, bug 923387 (which Michael is also maintainer of) for 
udisks2, where the dependency must be a Depends not a Recommends (so the 
workaround used for network-manager won't help). Like 921012, Michael 
closed it on 2020-03-15 and Mark re-opened it (since the bug wasn't 
resolved) on 2020-07-02, and there has been no input from him since. I 
submit that this is technically substantially the same issue, and that 
you might usefully rule on it unless Michael has told you he plans to 
fix that already. I don't think (especially given the incoming freeze) 
that it does anyone any good to have to re-hash the same arguments about 
that bug.


Regards,

Matthew

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

[Sean Whitton]

Hello,

On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote:

> On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
>
>> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
>> > My reasoning is that init scripts are the end goal, and that elogind is
>> > just a symptom of that end goal, and that therefore talking about
>> > elogind in isolation serves no purpose.
>> The GR specifically mentions elogind and not init scripts.
>
> "Technologies /such as/ elogind …" (emph. mine) shows to me that this
> is meant as an example, as a "demonstration", and not as an
> exhaustive list [0]. So neither is elogind "special" nor is it the
> only relevant piece of software to consider supporting. [1]

Yes, fair enough, thanks.

I think what is more relevant is that hard Depends: are harder to work
around than being asked to move files between coinstallable packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> We do drop features all the time between stable releases,
Russ> though, and generally that too is at the maintainer's
Russ> discretion.  The package maintainer's normal obligation in
Russ> Debian isn't to keep everything working that previously was
Russ> working, but to make it obvious when something is incompatible
Russ> (ideally before it breaks on a given system in a way that's
Russ> hard to back out of).

Agreed.

Russ> Often this is done by dropping or
Russ> renaming packages so that the old package just has no upgrade
Russ> path, but we handle it in other ways as well (release notes,
Russ> NEWS.Debian, etc., depending on the severity of the
Russ> incompatibility).

Agreed.
I think a reasonable way for the TC to handle the init script part of
this bug might be to politely suggest to the maintainer that they
include a note in the release notes.
(Or for a member of the TC to just propose such a note to the release
notes maintainers).
Russ> I guess the summary of my position on init scripts
Russ> specifically is that I generally agree with Wouter's framing
Russ> of two approaches to Debian who want very different things,
Russ> and I thought (at least for init scripts) we put a range of
Russ> options on the table from "you must support both approaches"
Russ> to "we're only going to support one approach," and the option
Russ> that people chose is "one option is strongly preferred but
Russ> individual maintainers can support other approaches if they
Russ> want to and we don't want to make exploration of other
Russ> approaches impossible."  The implication was that some
Russ> individual maintainers *won't* want to support other
Russ> approaches in their individual packages, and that's a decision
Russ> they get to make, and therefore folks who want to keep
Russ> sysvinit working should be exploring options that don't
Russ> require the maintainer incorporate that support (such as a
Russ> separate package of init scripts or a conversion utility that
Russ> generates init scripts from unit files).

We are in agreement here.  I guess that's not surprising given how many
times we have discussed this:-)

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

[Russ Allbery]

Sam Hartman  writes:

> The issue that came up in the policy discussion is that there may be
> implications for removing an init script.  As an example upgrades may
> break.  In the case of NetworkManager, you might find on an upgrade from
> buster to bullseye that you no longer have network because the init
> script disappeared.

> My recollection of the policy discussion is that there was a sense that
> we might want to say something about that if we managed to come up with
> a consensus, but we didn't want to block that on the general case.

> My take is that removing an init script is unambiguously okay under
> current policy as far as our policy on init scripts.  But for example,
> we have a rule that is fairly basic to our community that we don't break
> upgrades, or at least we try hard not to.  And it may well be that the
> TC or policy process could say more on that topic.

We do drop features all the time between stable releases, though, and
generally that too is at the maintainer's discretion.  The package
maintainer's normal obligation in Debian isn't to keep everything working
that previously was working, but to make it obvious when something is
incompatible (ideally before it breaks on a given system in a way that's
hard to back out of).  Often this is done by dropping or renaming packages
so that the old package just has no upgrade path, but we handle it in
other ways as well (release notes, NEWS.Debian, etc., depending on the
severity of the incompatibility).

That's what I took away from the point about not breaking upgrades.  I
think I may have interpreted "break" somewhat more narrowly than others,
given that.  To me, a broken upgrade is one in which the system stops
working without warning or loses data or the like.  If a package that used
to support MySQL and PostgreSQL now only supports PostgreSQL, that isn't a
"broken" upgrade as long as it's clearly advertised (in NEWS.Debian, in
release notes, etc.) and as long as it doesn't do something destructive
when it was previously using MySQL.

For example, one way that I would consider valid as a way to prevent
upgrades from breaking when one drops support for init systems that don't
support unit files would be to declare a dependency on the class of init
systems that do support unit files, so someone upgrading their system will
clearly see that they have to switch init systems or the package won't
work.  (This works particularly well if that's a change that apt will
decline to perform without special intervention.)  I think that's within
the normal sort of thing that package maintainers do when there are
incompatible changes to a package between stable releases.

I guess the summary of my position on init scripts specifically is that I
generally agree with Wouter's framing of two approaches to Debian who want
very different things, and I thought (at least for init scripts) we put a
range of options on the table from "you must support both approaches" to
"we're only going to support one approach," and the option that people
chose is "one option is strongly preferred but individual maintainers can
support other approaches if they want to and we don't want to make
exploration of other approaches impossible."  The implication was that
some individual maintainers *won't* want to support other approaches in
their individual packages, and that's a decision they get to make, and
therefore folks who want to keep sysvinit working should be exploring
options that don't require the maintainer incorporate that support (such
as a separate package of init scripts or a conversion utility that
generates init scripts from unit files).

Obviously (I hope) if a maintainer did take the dependency approach
mentioned above, there must be some straightforward path for a collection
of init scripts or a conversion utility to satisfy that dependency.
That's where the "project supports the efforts of developers working on
such technologies" part of the GR result comes in.

Just to be extremely clear, the dependency structure for logind feels
different to me and I don't have an opinion on that.

-- 
Russ Allbery (r...@debian.org)  

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

[Vincent Bernat]

 ❦ 28 décembre 2020 10:32 -05, Sam Hartman:

> But  for example, we have a rule that is fairly basic to our community
> that we don't break upgrades, or at least we try hard not to.

This is becoming harder and harder because we pile more and more choices
(init choice, initramfs choice, merged-usr choice). This is becoming
less and less relevant as more and more people are using containers or
disposable VM and upgrade is not a requirement anymore.

At some point, we have to become leaner.
-- 
The secret source of humor is not joy but sorrow; there is no humor in Heaven.
-- Mark Twain

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I think this clearly and unambiguously says that maintainers
Russ> can depend on unit support and drop init scripts from their
Russ> packages if they so choose, and that this choice only requires
Russ> as much justification as rejecting any other patch or feature
Russ> in their packages (and Debian is generally defers to package
Russ> maintainers here).

Russ> Apparently we still, after all that discussion, weren't on the
Russ> same page about this?  That's really unfortunate, since that
Russ> was one of the major questions on which we were trying to get
Russ> closure.

I'd like to be more optimistic.

during the policy discussion that led to the language you quoted later
in your message, we realized that

1) Do I need to include an new init script in a package

is a different question than

2) Should I drop an init script that already exists.

I think that the GR and policy discussion are unambiguous that
maintainers can (but need not) add an init script if they like.
A maintainer could for example reject an init script saying "I don't
want to spend the disk space, or I don't want to test that."

The issue that came up in the policy discussion is that there may be
implications for removing an init script.  As an example upgrades may
break.  In the case of NetworkManager, you might find on an upgrade from
buster to bullseye that you no longer have network because the init
script disappeared.

My recollection of the policy discussion is that there was a sense that
we might want to say something about that if we managed to come up with
a consensus, but we didn't want to block that on the general case.

My take is that removing an init script is unambiguously okay under
current policy as far as our policy on init scripts.
But  for example, we have a rule that is fairly basic to our community
that we don't break upgrades, or at least we try hard not to.
And it may well be that the TC or policy process could say more on that
topic.

Which is to say that I think in a specific case there might be a reason
why removing some init script that already existed would be a bad idea
even if we're agreed that no one has to add new init scripts unless they
want to.


signature.asc
Description: PGP signature

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

[Bdale Garbee]

Russ Allbery  writes:

> I assumed that if option B won, some
> maintainers would drop init scripts, and therefore if folks wanted to
> maintain a set of working init scripts, they'd need to look at different
> options than ensuring they were incorporated into each package.

I agree, this was my sense of what B meant at the time, too.

Bdale


signature.asc
Description: PGP signature

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

[Russ Allbery]

gregor herrmann  writes:

> What surprises me in this discussion: My very broad summary of the GR
> result was "systemd is the top priority, other init systems are
> supported on a best-effort basis", and now I'm reading statements which
> sound to me like "looking into new/future/niche init systems is ok-ish
> but we never meant sysvinit when we said 'alternate init systems'", and
> that's either a misunderstanding of some mails on my side or an
> interpretation I find implausible to draw from the text of the winning
> GR option.

The position that sysvinit specifically is a dead end but that Debian
should not lock ourselves into a single init system and instead be open to
using other init systems besides systemd was a position advocated by
several people during the GR debate, and if one held that position, it is
a reason to vote for the winning option B over option F (the focus on
systemd option).  Certainly my understanding at the time was that option B
was intended to represent the folks with that position, possibly among
others.

Whether the folks who voted B over other options meant it in that specific
way is, of course, somewhat unknowable, and I'm sure at least some of them
didn't.

This discussion surprises me for a somewhat different reason.  The winning
GR option contains this text, which I think is an evolution of text that I
asked for at the time to make things clearer from a Policy standpoint:

Packages may use any systemd facility at the package maintainer's
discretion, provided that this is consistent with other Policy
requirements and the normal expectation that packages shouldn't depend
on experimental or unsupported (in Debian) features of other packages.
Packages may include support for alternate init systems besides
systemd and may include alternatives for any systemd-specific
interfaces they use. Maintainers use their normal procedures for
deciding which patches to include.

I think this clearly and unambiguously says that maintainers can depend on
unit support and drop init scripts from their packages if they so choose,
and that this choice only requires as much justification as rejecting any
other patch or feature in their packages (and Debian is generally defers
to package maintainers here).

One of the GR discussion goals was to try to make all of the options clear
about the implications for whether or not maintainers could drop init
scripts from their packages or would be required to include them, and I
thought option B was one of the options that made it unambiguous that
maintainers could drop them.  I assumed that if option B won, some
maintainers would drop init scripts, and therefore if folks wanted to
maintain a set of working init scripts, they'd need to look at different
options than ensuring they were incorporated into each package.

Apparently we still, after all that discussion, weren't on the same page
about this?  That's really unfortunate, since that was one of the major
questions on which we were trying to get closure.

For the record, the current Policy language says:

Packages including a service unit may optionally include an init
script to support other init systems. In this case, the init script
should have the same name as the systemd service unit so that systemd
will ignore it and use the service unit instead. Packages may also
support other init systems by including configuration in the native
format of those init systems.

I have another pending patch that I need to finish revising that makes the
normative language here more explicit.  The intended definition of "may"
here is the one from that patch, namely:

* The term *may* and the adjective *optional* are used to clarify cases
  where it may otherwise appear that Policy is specifying a requirement or
  recommendation. In those cases, these words describe decisions that are
  truly optional and at the maintainer's discretion.

This was intended to reflect the result of the GR.

The dependency structure for indicating a logind requirement is a more
complicated question and I don't personally have any opinion about the
GR's implications for it.

-- 
Russ Allbery (r...@debian.org)  

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

[gregor herrmann]

On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:

> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> > My reasoning is that init scripts are the end goal, and that elogind is
> > just a symptom of that end goal, and that therefore talking about
> > elogind in isolation serves no purpose.
> The GR specifically mentions elogind and not init scripts.

"Technologies /such as/ elogind …" (emph. mine) shows to me that this
is meant as an example, as a "demonstration", and not as an
exhaustive list [0]. So neither is elogind "special" nor is it the
only relevant piece of software to consider supporting. [1]


What surprises me in this discussion: My very broad summary of the GR
result was "systemd is the top priority, other init systems are
supported on a best-effort basis", and now I'm reading statements
which sound to me like "looking into new/future/niche init systems is
ok-ish but we never meant sysvinit when we said 'alternate init
systems'", and that's either a misunderstanding of some mails on my
side or an interpretation I find implausible to draw from the text of
the winning GR option.


Cheers,
gregor


[0] in German (and probably Roman) legal terms, "demonstrativ" vs.
"taxativ", cf. https://de.wikipedia.org/wiki/Enumerationsprinzip and
https://dict.leo.org/forum/viewWrongentry.php?idThread=40524=ende=en

[1] I also think that this is an example of why naming one specific
software in a normative text is not such a good idea.

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Carole King: Smackwater Jack


signature.asc
Description: Digital Signature

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

[Sean Whitton]

Hello Wouter,

On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:

> My reasoning is that init scripts are the end goal, and that elogind is
> just a symptom of that end goal, and that therefore talking about
> elogind in isolation serves no purpose.

The GR specifically mentions elogind and not init scripts.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Wouter Verhelst]

Hi Sam,

On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst  writes:
> Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> >> I think that we should either decide that
> >> 
> >> 1) NetworkManager should support elogind
> >> 
> >> or
> >> 
> >> 2) That we haven't seen enough development of alternatives to
> >> systemd and the project consensus on the GR has changed.
> 
> Wouter> Personally, I think both of these options are terrible and
> Wouter> will fail to fix the situation long term.
> 
> You then go on to talk about init scripts.

If that is what you took away from my email, then I should probably have
written it differently so my message was clearer. Apologies about that.

I don't think that either elogind or init scripts are really the heart
of the matter here. What matters is that there are two opposing visions
about what Debian should become, that both these visions have valid
technical needs, and that deciding that we have to go with one or the
other isn't going to solve the issue; people will continue talking about
wanting to do what they want to do.

Debian isn't Fedora. Fedora has a "steering committee" (FESCo) which
decides on what to use in the future, and their word is final. If you
want to do something in Fedora that FESCo decided against, you're out of
luck. It means far less arguments, and there is something to be said for
doing things that way, but historically, it's not what Debian has done.
In my opinion, this diversity is one of our strengths, and making a
decision either way like you suggest is not going to help anyone.

> I found that really frustrating because I was talking about elogind,
> not init scripts.

Honestly, I don't think you can realistically do that. The no-systemd
people don't actually care about elogind; they only want it because
there is software out there which requires an interface provided by
logind, and elogind provides the same interface outside of systemd, and
so you can theoretically run NetworkManager without systemd if you
install elogind, or something along those lines. So while making a
decision about elogind may solve the bug at hand, it doesn't really
address the bigger issue, and then if we do that we'll be back here in
six months. Perhaps that's all we can do, but I do think it's worth
pointing out that it will happen.

As far as "developing alternatives" go: as I understand it, the end goal
for no-systemd people is not "something that doesn't exist yet".
Instead, the end goal is "we want to use what we have been using a long
time and what we thinks works just fine and we don't want this
newfangled mess, thank you very much". By allowing them to use elogind
but not init scripts, and then telling them that they have to write
something not-initscripts and also not-systemd if they want to move
forward within Debian, you're not saying something they want to hear.
That is, unless your end goal is to tell them to go do their thing
somewhere outside of Debian (which would be a valid position if it
happens to be how you feel about the issue, but it's not one I share).

In other words, I think the two are entangled, and I don't think you can
decide to only handle one of the two if you want to solve the issue at
hand.

(however, it is certainly possible to provide different solutions for
the two; e.g., you can say that the maintainer should add elogind as an
alternative dependency, but that init scripts should be elsewhere, in a
package maintained by no-systemd people)

> My reasoning doesn't apply to init scripts, I never said it did, and I
> even gave entirely different reasoning about init scripts because I
> don't think the text you quoted is a good place to think about init
> scripts.

My reasoning is that init scripts are the end goal, and that elogind is
just a symptom of that end goal, and that therefore talking about
elogind in isolation serves no purpose.

> The GR, policy, and our discussions treat elogind and init scripts
> differently.  I support the consensus of debian-policy, the and the
> majority of project members who voted in the GR in treating these issues
> differently.

I don't think that's actually the case; but the vote was rather muddled
because some options on the ballot were written by people who didn't
actually support the position they were writing, so I can't say for
sure.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

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

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
>> I think that we should either decide that
>> 
>> 1) NetworkManager should support elogind
>> 
>> or
>> 
>> 2) That we haven't seen enough development of alternatives to
>> systemd and the project consensus on the GR has changed.

Wouter> Personally, I think both of these options are terrible and
Wouter> will fail to fix the situation long term.

You then go on to talk about init scripts.

I found that really frustrating because
I was talking about
elogind, not init scripts.

My reasoning doesn't apply to init scripts, I never said it did, and I
even gave entirely different reasoning about init scripts because I
don't think the text you quoted is a good place to think about init
scripts.

The GR, policy, and our discussions treat elogind and init scripts
differently.  I support the consensus of debian-policy, the and the
majority of project members who voted in the GR in treating these issues
differently.

--Sam

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

[Wouter Verhelst]

On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> I think that we should either decide that
> 
> 1) NetworkManager should support elogind
> 
> or
> 
> 2) That we haven't seen enough development of alternatives to systemd
> and the project consensus on the GR has changed.

Personally, I think both of these options are terrible and will fail to
fix the situation long term.

There are people in Debian who would rather not see that they have to
carry init scripts in their packages. For better or for worse, these
init scripts are a relic of the past for such people, and they do not
want to have to work on them. And while Debian does have some ways of
collaborating across package boundaries, it's not really something we
are very good at, culturally. Given that the GR has given init scripts
lower priority nowadays, dropping the init script is not an RC bug
anymore, and therefore people in this group feel that it's just fine to
drop their init scripts and let people who care about alternatives deal
with the fallout of that.

At the same time, there are people in Debian who would rather not run
systemd on their systems, and who want to put in the work to make sure
that some alternative (of whatever form they prefer) is usable and
available in Debian. These developers seem willing to fix bugs when they
appear, but for reasons they've explained elsewhere in the thread are
unwilling to group all the sysvinit-specific stuff in a single package
and deal with it that way.

It feels to me that any solution that prescribes that people in the
first group need to do something which means they can't actually drop
the init scripts, or alternatively any solution which does not provide a
clear way forward for people in the second group on how they will be
able to do what they would like to achieve, is doomed to failure.

People in the first group are not going to magically change their mind
and want to put in the work. Any solution that prescribes that they have
to will fail the constitutional requirement that nobody can be forced to
do anything they do not want.

People in the second group are not going to magically change their mind
and want to stop using something not systemd. Any solution that
prescribes that they have to will fail the very same constitutional
requirement.

I think whatever the TC comes up with will need to incorporate the valid
needs and wants of both groups if it is going to succeed in settling the
argument.

Both the solutions which you suggest fail to meet this bar, from where
I'm standing.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

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

[Mark Hindley]

Elana,

Thanks for passing this on.

On Mon, Dec 21, 2020 at 03:36:45PM -0800, Elana Hashman wrote:
> Less than 1% of users are installing sysvinit-core, with a steady
> downward trend.[1]

I accept that the number of users is small, although the figures referenced omit
users of openrc and runit. It is also worth noting that is is currently
moderately difficult to switch away from systemd to another init. Suggestions of
ways of making this more user friendly have been rejected[1]. In this case using
popcon as definitive evidence of the actual demand seems questionable.

> elogind is very difficult to support in its current state (see the
> following bugs: [2] [3] [4] [5]), which is why Michael does not want to
> maintain support for it.

He may not want to, but I still see no technical or other reason why this should
be blocked: elogind has been in the archive since buster; it is specifically
mentioned in the winning GR option as technology to explore; the logind and
default-logind virtual packages have been in the Policy since version 4.4.0 of
July 2019

My assessment of the bugs that Michael references is rather different.

 - #923244 was resolved in February 2019 and whilst I realise that Michael
remains unhappy with the way that resolution was achieved, the solution
works for both non-systemd users and systemd users and I am not aware of any
regressions.

 - #934491 was closed after being fixed by the resolution of #935910 in apt.

 - #959920 was really about systemctl providing systemd, and only indirectly
related to elogind (which conflicts with systemd, as you would expect).

 - #968379 was resolved with the latest upstream release of elogind.

Although elogind inclusion and support was controversial and hard-won, these
specific issues have been resolved. Making use of the default-logind and logind
virtual packages actually makes elogind rather easy to support.

Mark


[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935304

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

[Ian Jackson]

Matthew writes:
> * We've talked about the burden already; there are people willing and
>   able to help with this, and that offer remains good, be that by
>   providing patches, MRs, help with bug reports on non-systemd systems,
>   NMUs, or some other mechanism that Michael would prefer

I think that it is worth mentioning, in this context, the burden on
the other side.  That is, the burden Debian places on those who want
to "explore alternatives to systemd", as the GR puts it.

The non-systemd community has suffered many unexplained or
poorly-explained deletions of working functionality, and several other
kinds of blockages.  Each time we need very careful escalation to the
DPL and the TC etc. [1]

This continual fight to not have working things deleted (or broken
without good reason) is *much* more work than we are asking of the
maintainers of core packages like network-manager.

The opposition we face, and the consequential burden of constant
emotional and political attrition is *the only real impediment* to
having really good support for alternative init systems in Debian.

It is also a drain on the energy of the people who would otherwise be
developing and integrating alternatives to both systemd and sysvinit.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

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

[Matthew Vernon]

Hi,

On 21/12/2020 23:36, Elana Hashman wrote:


The maintainer, Michael Biebl, reached out to the tech-ctte privately. I
have summarized his reasoning for why he dropped support for elogind and
the init script that prompted this bug:


Thanks. There's little point trying to have this discussion with Michael 
by proxy, I suspect, but I thought I would make a couple of observations 
on what he says; I will try and not repeat myself too much, although he 
does raise things that have already come up in this bug.


* While we have largely talked about sysvinit here, the issues here do 
relate to other init systems - elogind integration is useful for all 
non-systemd inits


* I appreciate that there is a tension between maximally integrating 
systemd-specific features into the distribution and maintaining 
compatibility with other init systems. There was an option to do so in 
the init system GR, and it did not win. So while the GR allowed for 
project consensus to shift over time, I don't think acting as if option 
F "focus on systemd" won within the same release cycle is really on


* We've talked about the burden already; there are people willing and 
able to help with this, and that offer remains good, be that by 
providing patches, MRs, help with bug reports on non-systemd systems, 
NMUs, or some other mechanism that Michael would prefer


* I think the difficulty of elogind support is overstated - in the case 
of network-manager, there are a number of people who are running it thus 
without issue


Regards,

Matthew

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

[Elana Hashman]

On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote:
> 
> I caution folks from speculating too much on the maintainer's
> motivations and reasoning while they haven't yet had a chance to share
> their perspective on the bug. :)
> 
> From what I can see reading through both #964139 and #960780, no
> technical rationale has been given for why the script was removed, only
> a statement that the removal was intentional.[0]
> 
> It would be much appreciated if Michael Biebl or another maintainer from
> the Utopia team could add some context here.
> 
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139#62

The maintainer, Michael Biebl, reached out to the tech-ctte privately. I
have summarized his reasoning for why he dropped support for elogind and
the init script that prompted this bug:


Less than 1% of users are installing sysvinit-core, with a steady
downward trend.[1]

If we require packages to maintain sysvinit support, then this cements
sysvinit/sysv-rc as the least common denominator for packages and blocks
the use of many of systemd's features, such as timers. This results in
an OS that is less integrated than it could be, which hurts the vast
majority of users who do not use sysvinit.

Trying to support multiple init systems generates a lot of additional
work for maintainers, who are already stretched thin. Time and energy
are limited resources, and triaging and root-causing bugs from
supporting multiple init systems take a lot of time; maintaining an init
script comprises only a small part of the support burden.

elogind is very difficult to support in its current state (see the
following bugs: [2] [3] [4] [5]), which is why Michael does not want to
maintain support for it.

[1] https://qa.debian.org/popcon.php?package=sysvinit
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968379
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959920


Feel free to direct any questions to me.

- e


signature.asc
Description: PGP signature

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

[lorenzo]

On Wed, 16 Dec 2020 11:48:52 +0100
Philip Hands  wrote:

> Are Simon's suggested dependencies are better in this regard?

As far as I know

> default-logind | logind

works fine, but something like

> systemd-sysv | network-manager-nonsystemd,

won't for the same reason mentioned in my previous message.
I agree that would be nice to have the package that ships
your favorite init scripts automatically installed even when you are not
running the default (systemd), but I'm not sure there is a way to
express that kind of dependency with apt :(

Regards,
Lorenzo 

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

[Philip Hands]

Matthew Vernon  writes:

> On 14/12/2020 21:56, Philip Hands wrote:
>
>> Could I just check if there's a point of common acceptability which both
>> sides of this discussion could live with?
>
> [...]
>
>> My suggestion for a mutually bearable solution would be that the
>> network-manager package could have its dependency on libpam-systemd
>> changed to instead be something like:
>> 
>>libpam-systemd | network-manager-nonsystemd
>
> Is this instead of the logind virtual package? I'm not quite sure what 
> problem you're trying to solve here, but I'm don't think it generalises 
> well (you'd end up with potentially lots of package that just Depend on 
> logind and maybe contain an init script); and without any input from the 
> network-manager maintainer about why they were unwilling to take the 
> patch to use the existing virtual package, I'm not sure why this should 
> be more acceptable.

If that were the way things were going, then I'd expect one to end up
with a package that bundled all the init scripts, and provided whatever
virtual packages etc. required to glue all the bits together somehow.

The details of how to do that seemed like things that should be between
the people maintaining the two sets of packages, and I wasn't worrying
about the details too much, because I was rather hoping that it wouldn't
actually be needed.

>> If you think this approach is impractical for some reason, please say
>> so, because what I have in mind as a better option does rather rely on
>> this being available as a plausible fall-back position.
>
> I'm confused as to why you don't just tell us what your better option is.

My better option was that having defined the areas of responsibility by
thinking about who'd do what in a split package setup, we might manage
to agree that the same people could take the same responsibility for
maintaining those bits in the places where they would need to be in the
packages as they stand.

For that to work, I think the maintainer would have to have the right to
declare that they didn't think the experiment was working out
(presumably because of drowning in bugs that were not being handled in a
sensible time, say) at which point the already agreed split package
setup would provide an acceptable plan B.

That would hopefully allow the maintainer to relax enough about having
some new people co-maintaining some fragments of the package to give
space for everyone to demonstrate that it was possible for them to work
together.

There's nothing specific to NM in any of that BTW, so if other packages
are in this position where constructive cooperation really ought to
work, but there's just a little too much distrust at present, then maybe
you can give this a try there.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Ansgar]

On Wed, 2020-12-16 at 14:46 +, Matthew Vernon wrote:

Not is it straightforwardly clear that "alternative init systems"
should in fact be interpreted to mean "alternative init systems (but
not 
sysvinit)".

The GR text mostly seems to talk about *exploring* alternatives;
continuing to maintain a 30 year old system doesn't really seem
explorative work to me?  Even retiring sysvinit support completely
seems fine with the GR's text.

Besides preserving sysvinit in its current state (arguably not
exploration), not much else seems to happen with regard to alternatives
to systemd as far as I am aware?

For exploration, much less support is needed: to install systemd-sysv
you had to fight with dpkg to uninstall / keep away an essential
package (sysvinit) for several years or choose alternative routes (e.g.
specify init= on the kernel command-line); you might have needed to
write .service units yourself to start services using systemd's native
facilities instead of a (limited, but well-working) compatibility
layer.  I still have some custom .service units for packages that don't
ship one themselves.

Arguably having to create "fake" packages using `equivs` or similar
tools to satisfy dependencies one would like to force to be avoided
would be comparable to having to remove essential packages?

Not having all packages ship a sysvinit script must also be more or
less expected: we have 250+ packages shipping .service files, but no
sysvinit scripts in current testing.  I already filtered out any
packages shipping DBus .service files and some packages part of the
systemd/sysvinit implementation itself for this, but there are some
other false postives like .timer units with their associated .service
unit that have equivalent cronjobs (though some might miss a cronjob as
well).  For comparison: 980 packages in total have any .service system
units and 1057 have a sysvinit script (excluding the packages part of
systemd/sysvinit itself.)

In addition some package use other systemd-provided facilities that
elogind conflicts with, e.g., systemd-tmpfiles; or systemd-hostnamed
here for NM (AFAIU).

As you already said you would like the technical committee to rule that
similar changes should not be blocked by maintainer of other packages
and already said you have some packages in mind, I think it would be
interesting to know which ones you are talking about.  Would
maintainers have to accept patches stopping use of systemd-tmpfiles,
systemd-hostnamed, ...?

Ansgar

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

[Sam Hartman]

> "Matthew" == Matthew Vernon  writes:

Matthew> On 15/12/2020 22:07, Sam Hartman wrote:
>>> However, Debian remains an environment where developers and
>>> users can explore and develop alternate init systems and
>>> alternatives to systemd features.  Those interested in exploring
>>> such alternatives need to provide the necessary development and
>>> packaging resources to do that work.  Technologies such as
>>> elogind that facilitate exploring alternatives while running
>>> software that depends on some systemd interfaces remain
>>> important to Debian.  It is important that the project support
>>> the efforts of developers working on such technologies where
>>> there is overlap between these technologies and the rest of the
>>> project, for example by reviewing patches and participating in
>>> discussions in a timely manner.
>> 
>> We did not say in that GR that we were interested in supporting
>> ongoing development of sysvinit.

Matthew> I find it surprising that, in a TC bug about (inter alia)
Matthew> whether a dependency on libpam-systemd should be changed to
Matthew> default-logind | logind i.e. to facilitate use of elogind
Matthew> you appear to be saying that a GR text that talks about the
Matthew> importance of "technologies such as elogind" should be
Matthew> interpreted as meaning in effect that actually it isn't all
Matthew> that important and network-manager should continue to have
Matthew> effectively a systemd-only dependency.

I'd like to be heard differently.
I think that we should either decide that

1) NetworkManager should support elogind

or

2) That we haven't seen enough development of alternatives to systemd
and the project consensus on the GR has changed.



Matthew> Not is it straightforwardly clear that "alternative init
Matthew> systems" should in fact be interpreted to mean "alternative
Matthew> init systems (but not sysvinit)".

I'd like to be heard differently on this point too.
I think that to the extent that people are doing things like adding
support for service units, looking at ways of solving problems that
motivated systemd in non systemd ways in the sysvinit ecosystem, that
clearly counts as development of alternative init systems in the scope
of the GR.

I think that maintaining sysvinit for stable releases so that users can
use it does not count as development of alternate init systems.
I understand that several people in the project want to do that work.
I'm not speaking against that work here, but I don't think you can use
the GR as support for that work.

Matthew> Nor is this a case of someone demanding that the
Matthew> network-manager maintainer provide a sysvinit script nor
Matthew> fix the bugs in an existing-but-broken one.

Understood.
I did suggest to Mark that he use that argument in arguing for
maintaining the init script.
As I mentioned policy process was not able to come to consensus on when
to remove existing init scripts.


--Sam

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

[Matthew Vernon]

On 14/12/2020 21:56, Philip Hands wrote:


Could I just check if there's a point of common acceptability which both
sides of this discussion could live with?


[...]


My suggestion for a mutually bearable solution would be that the
network-manager package could have its dependency on libpam-systemd
changed to instead be something like:

   libpam-systemd | network-manager-nonsystemd


Is this instead of the logind virtual package? I'm not quite sure what 
problem you're trying to solve here, but I'm don't think it generalises 
well (you'd end up with potentially lots of package that just Depend on 
logind and maybe contain an init script); and without any input from the 
network-manager maintainer about why they were unwilling to take the 
patch to use the existing virtual package, I'm not sure why this should 
be more acceptable.



If you think this approach is impractical for some reason, please say
so, because what I have in mind as a better option does rather rely on
this being available as a plausible fall-back position.


I'm confused as to why you don't just tell us what your better option is.

Regards,

Matthew

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

[Matthew Vernon]

On 15/12/2020 22:07, Sam Hartman wrote:


However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features.  Those interested in exploring such alternatives need to
provide the necessary development and packaging resources to do that
work.  Technologies such as elogind that facilitate exploring
alternatives while running software that depends on some systemd
interfaces remain important to Debian.  It is important that the
project support the efforts of developers working on such technologies
where there is overlap between these technologies and the rest of the
project, for example by reviewing patches and participating in
discussions in a timely manner.


We did not say in that GR that we were interested in supporting ongoing
development of sysvinit.


I find it surprising that, in a TC bug about (inter alia) whether a 
dependency on libpam-systemd should be changed to default-logind | 
logind i.e. to facilitate use of elogind you appear to be saying that a 
GR text that talks about the importance of "technologies such as 
elogind" should be interpreted as meaning in effect that actually it 
isn't all that important and network-manager should continue to have 
effectively a systemd-only dependency.


Not is it straightforwardly clear that "alternative init systems" should 
in fact be interpreted to mean "alternative init systems (but not 
sysvinit)".


Nor is this a case of someone demanding that the network-manager 
maintainer provide a sysvinit script nor fix the bugs in an 
existing-but-broken one.


By analogy, consider a Finnish translation for a package - as a 
maintainer I don't know enough Finnish to write nor usefully evaluate a 
particular translation; but I apply it to my package if one is supplied. 
If it's erroneous enough that bug reports pile up about it and no-one 
supplies a fix, I might eventually pull it from the package. But some of 
the arguments in this thread seem quite close to "non-systemd users 
might have a slightly less good experience with network-manager, so we 
should prevent them from using it at all" - which would be like me 
deciding that my Finnish users might get slightly imperfect messages so 
I shouldn't support that language at all.


Regards,

Matthew

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

[Philip Hands]

lorenzo  writes:

> Hi all,
>
>> My suggestion for a mutually bearable solution would be that the
>> network-manager package could have its dependency on libpam-systemd
>> changed to instead be something like:
>>
>>  libpam-systemd | network-manager-nonsystemd
>
> Please consider that apt has issues with or group depends/recommends:
> Unless the first option listed is a virtual (nonexistent) package, it
> will force an init switch on install.
> For an example (with Recommends), see #953875 #47 and below

Good point.

I was mostly interested in seeing if there might be a package split that
would provide a division of responsibility where those that want the
work done get to do it without burdoning others with a lot of effort.

The details of the dependencies surrounding those packages would of
course be important if it were eventually decided to really implement
that solution -- if it is impossible to implement with apt, then that
certainly is a problem with this approach.

Are Simon's suggested dependencies are better in this regard?

(I was rather hoping that this would end up being the sort of detail
that would get agreed between the maintainers of the packages involved,
madly optimistic fool that I am ;-) )

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[lorenzo]

Hi all,

> My suggestion for a mutually bearable solution would be that the
> network-manager package could have its dependency on libpam-systemd
> changed to instead be something like:
>
>  libpam-systemd | network-manager-nonsystemd

Please consider that apt has issues with or group depends/recommends:
Unless the first option listed is a virtual (nonexistent) package, it
will force an init switch on install.
For an example (with Recommends), see #953875 #47 and below

Regards,
Lorenzo

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

[Sam Hartman]

I had a great discussion with Mark Hindley about this issue a few months
ago.
I'd like to summarize what I said in that discussion as input to the TC.

But I'd also like to start out by reminding us all what we said in the
GR text that we agreed to.

As one of the contributors to that text, you might either think I'm in a
good or a bad position to interpret it, depending on how you think about
such things.
I think it's clear I've  thought about the problem space somewhat.


>However, Debian remains an environment where developers and users can
>explore and develop alternate init systems and alternatives to systemd
>features.  Those interested in exploring such alternatives need to
>provide the necessary development and packaging resources to do that
>work.  Technologies such as elogind that facilitate exploring
>alternatives while running software that depends on some systemd
>interfaces remain important to Debian.  It is important that the
>project support the efforts of developers working on such technologies
>where there is overlap between these technologies and the rest of the
>project, for example by reviewing patches and participating in
>discussions in a timely manner.

We did not say in that GR that we were interested in supporting ongoing
development of sysvinit.
Certainly, in my advocacy post for the winning option, I argued that
didn't make sense to me.
We said only that we were interested in the facilities to allow people
to develop alternate init systems.
(We did not say we wanted to throw sysvinit away either, but the project
did not commit in the GR to interest in sysvinit).

We also said:

>The Debian project recognizes that systemd service units are the
>preferred configuration for describing how to start a daemon/service.

That has been further codified in policy as I'll discuss below.
I'd think that by the time an alternate init system becomes a plausible
general purpose alternative to systemd, it needs to support service
units.

We also said:

Using its power under Constitution section 4.1 (5), the project issues
>the following statement describing our current position on Init
>systems, Init system diversity, and the use of systemd facilities.  This
>statement describes the position of the project at the time it is
>adopted.  That position may evolve as time passes without the need to
>resort to future general resolutions.

So, the consensus can evolve  as we watch what people do, and we see how
valuable development of alternate init systems is.
Personally, I think that an important consideration would be how much
actual development of init systems are we seeing vs how much
maintenance of existing init systems are we seeing.
If we're seeing people who are actively working to solve the problems
that made systemd attractive in other ways, writing new code, that sort
of thing, I'd hope that we would support that work and get it unblocked.
If all we're seeing is maintenance of the same existing init systems, my
personal view is that's not what the winning GR option was about.

Other things we did not say.  We didn't say other init systems would be
in bullseye (nor did we say they would not).  In my mind,  we committed
to allowing developers to experiment, not at this time to making any
particular init system beyond systemd ready for release.
Now, presumably, if someone comes up with some great new init system
that solves the problems that makes systemd attractive over sysvinit to
a number of users in ways that are different/better, we'd probably like
to include it in a release.
If sysvinit's users and maintainers can get it ready to be releasable
we'd probably like to do that, although I don't think the GR applies to
that work so much as the work necessary to allow development to
continue.

I'll close with my comments to Mark, which touch on how this all
interacts with policy as I understand it.
I'm mostly going to avoid value judgments and focus on my understanding
of what Debian decided in the vote and what our policy is, and try and
help you accomplish your goals under that set of constraints.

The short of it is that I think we decided that init scripts are purely
optionalal.
As a consequence, I think that any alternate init system needs to handle
service units, or some significant subset of them, to be useful.
But see below.

I think there are two issues here.
I actually think that you have a reasonably good case for escalating
the NetworkManager support for the virtual logind packages.
In particular, our GR said we were interested in  facilitating that
work.
So, I think it would be reasonable to ask what's going on with that and
ask for help trying to work through that.

The init script case is more problematic.

You don't explain why NetworkManager should have an init script,
and the current thinking in Debian policy is that were it a new package,
it probably should not.

Quoting section 9.3.1 of 

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

[Vincent Bernat]

 ❦ 15 décembre 2020 11:14 GMT, Mark Hindley:

>> Okay, great, I now see a clearer argument in favour of dropping the init
>> script: enabling the maintainer to preemptively avoid dealing with bugs
>> which are likely to generate hostility, rather than just the idea that
>> there could be bugs which would generate a lot of technical work for the
>> maintainer in which the maintainer does not see much value.
>
> I am afraid I don't agree with this.
>
> Hostility is never justified or justifiable and none of us should ever have 
> to be
> subject to it or tolerate it.  However, using the avoidance of putative poor
> behaviour by others in the future as a justification for a current or past 
> action
> seems a weak argument to me. IMO, the best way to promote the ideals of
> tolerance, courtesy, humility and openness is by espousing them in one's 
> actions
> and by doing the right thing.

Poor behaviour happened in the past. Almost nothing (literally) is
needed to trigger a flamewar around an initscript.

https://lists.dyne.org/lurker/message/20171024.145026.a763a9da.en.html
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Sean Whitton]

Hello,

On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote:

> Sean and Simon,
>
> On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
>> > In the cases where the regression was accidental, ideally, the answer
>> > would be someone calmly and politely offering a tested patch, but it
>> > sadly seems equally likely to result in hostility, and I think it's
>> > reasonable for a maintainer to try to avoid that preemptively by making
>> > it clear that the LSB init script is someone else's responsibility.
>> > Our volunteers are not automata, and I think maintainers need to be able
>> > to set boundaries for their responsibilities to protect their mental state.
>> >
>> > Similarly, in the case where the dependency is deliberate, I don't
>> > think we want the responsibilities of a Debian maintainer to include
>> > interceding between angry sysvinit users and upstream.
>>
>> Okay, great, I now see a clearer argument in favour of dropping the init
>> script: enabling the maintainer to preemptively avoid dealing with bugs
>> which are likely to generate hostility, rather than just the idea that
>> there could be bugs which would generate a lot of technical work for the
>> maintainer in which the maintainer does not see much value.
>
> I am afraid I don't agree with this.
>
> Hostility is never justified or justifiable and none of us should ever have 
> to be
> subject to it or tolerate it.  However, using the avoidance of putative poor
> behaviour by others in the future as a justification for a current or past 
> action
> seems a weak argument to me. IMO, the best way to promote the ideals of
> tolerance, courtesy, humility and openness is by espousing them in one's 
> actions
> and by doing the right thing.

It would not be good to assume that there are never circumstances in
which preemptively avoiding hostility by refusing to engage with certain
technical options is a reasonable thing for a maintainer to do, but
whether it is something the project can accept in this particular case
is still in question.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Mark Hindley]

Sean and Simon,

On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
> > In the cases where the regression was accidental, ideally, the answer
> > would be someone calmly and politely offering a tested patch, but it
> > sadly seems equally likely to result in hostility, and I think it's
> > reasonable for a maintainer to try to avoid that preemptively by making
> > it clear that the LSB init script is someone else's responsibility.
> > Our volunteers are not automata, and I think maintainers need to be able
> > to set boundaries for their responsibilities to protect their mental state.
> >
> > Similarly, in the case where the dependency is deliberate, I don't
> > think we want the responsibilities of a Debian maintainer to include
> > interceding between angry sysvinit users and upstream.
> 
> Okay, great, I now see a clearer argument in favour of dropping the init
> script: enabling the maintainer to preemptively avoid dealing with bugs
> which are likely to generate hostility, rather than just the idea that
> there could be bugs which would generate a lot of technical work for the
> maintainer in which the maintainer does not see much value.

I am afraid I don't agree with this.

Hostility is never justified or justifiable and none of us should ever have to 
be
subject to it or tolerate it.  However, using the avoidance of putative poor
behaviour by others in the future as a justification for a current or past 
action
seems a weak argument to me. IMO, the best way to promote the ideals of
tolerance, courtesy, humility and openness is by espousing them in one's actions
and by doing the right thing.

Mark

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

[Mark Hindley]

On Tue, Dec 15, 2020 at 09:51:56AM +, Simon McVittie wrote:
> On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote:
> > Could I just check if there's a point of common acceptability which both
> > sides of this discussion could live with?
> >
> >   libpam-systemd | network-manager-nonsystemd
> 
> Presumably this is an optimized form of what we perhaps conceptually mean:
> 
> default-logind | logind,
> systemd-sysv | network-manager-nonsystemd,
> 
> i.e. it needs a logind implementation (preferably our default, which we
> happen to know is systemd's), plus either systemd or some glue to support
> running the daemon without systemd?
> 
> (I agree that the optimized form is clearer and probably less work for
> apt's resolver than the unoptimized form, as long as systemd being our
> default is not in doubt - but I'm mentioning the unoptimized form because
> I think it might illustrate the motivation better.)

Actually, I think the long form is clearer both semantically and in that it
clearly separates the functionality of the options.

Mark

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

[Simon McVittie]

On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote:
> Could I just check if there's a point of common acceptability which both
> sides of this discussion could live with?
>
>   libpam-systemd | network-manager-nonsystemd

Presumably this is an optimized form of what we perhaps conceptually mean:

default-logind | logind,
systemd-sysv | network-manager-nonsystemd,

i.e. it needs a logind implementation (preferably our default, which we
happen to know is systemd's), plus either systemd or some glue to support
running the daemon without systemd?

(I agree that the optimized form is clearer and probably less work for
apt's resolver than the unoptimized form, as long as systemd being our
default is not in doubt - but I'm mentioning the unoptimized form because
I think it might illustrate the motivation better.)

smcv

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

[Philip Hands]

Sean Whitton  writes:

> It is difficult to think further about this without input from the
> maintainer as to how much this was a part of his motivation, and what
> experiences he has had led him to think in that way.

Hi All,

Could I just check if there's a point of common acceptability which both
sides of this discussion could live with?

Please don't assume that I'm offering this as a preferred outcome. I
would hope that we can come up with something better than this, but I
think that agreeing that this is an acceptable and achievable baseline
would provide a foundation on which to build something better.

My suggestion for a mutually bearable solution would be that the
network-manager package could have its dependency on libpam-systemd
changed to instead be something like:

  libpam-systemd | network-manager-nonsystemd

and that the init diversity folks could then take responsibility for
satisfying that optional dependency as they see fit in order to keep
network-manager available on non-systemd systems, which should insulate
the network-manager maintainer from almost all of the effort involved.

I say 'almost all' because I would imagine that non-systemd-related bugs
might be reported against network-manager occasionally, and need to be
reassigned, and one could also imagine that upstream might change things
in a way that was clearly going to break things on non-systemd systems,
in which case it would be polite if the network-manager maintainer would
open a bug mentioning that change against the network-manager-nonsystemd
package, etc.

If you think this approach is impractical for some reason, please say
so, because what I have in mind as a better option does rather rely on
this being available as a plausible fall-back position.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote:

> On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
>
>> Participants in the thread who have argued on that side of the
>> discussion seem to implicitly rely on the idea that a package maintainer
>> is responsible for applying an equally high level of quality assurance
>> to every file or feature in their package, as that which they would
>> apply to its most basic or flagship features.
>
> Ordinarily, perhaps yes. However, for whatever reason, people are
> particularly emotionally attached to particular init systems (or perhaps
> to the absence of systemd). We can see this here already: I don't think a
> dependency on a particular httpd or email server would have been brought
> to the technical committee asking for a maintainer to be overruled,
> and it seems unlikely to have had participants describing a maintainer
> declining an NMU as an outrage.
>
> If NM's LSB init script was present, but stopped working - perhaps
> because upstream deliberately made more use of systemd facilities, or
> because upstream accidentally relied on systemd facilities due to none of
> the upstream developers using anything else, or because the command-line
> syntax changed and the upstream-provided systemd unit was updated but the
> downstream init script wasn't - what do we expect to happen?
>
> In the cases where the regression was accidental, ideally, the answer
> would be someone calmly and politely offering a tested patch, but it
> sadly seems equally likely to result in hostility, and I think it's
> reasonable for a maintainer to try to avoid that preemptively by making
> it clear that the LSB init script is someone else's responsibility.
> Our volunteers are not automata, and I think maintainers need to be able
> to set boundaries for their responsibilities to protect their mental state.
>
> Similarly, in the case where the dependency is deliberate, I don't
> think we want the responsibilities of a Debian maintainer to include
> interceding between angry sysvinit users and upstream.

Okay, great, I now see a clearer argument in favour of dropping the init
script: enabling the maintainer to preemptively avoid dealing with bugs
which are likely to generate hostility, rather than just the idea that
there could be bugs which would generate a lot of technical work for the
maintainer in which the maintainer does not see much value.

It is difficult to think further about this without input from the
maintainer as to how much this was a part of his motivation, and what
experiences he has had led him to think in that way.

>> We want maintainers to
>> perform testing which is adequate to ensure that the core features of a
>> package won't regress if they upload a new version, but we do not take
>> maintainers to be responsible for testing every optional feature and we
>> accept that such things might be temporarily broken until someone other
>> than the maintainer can provide a patch.
>
> I think perhaps you have higher expectations of bug reporters than I do
> - perhaps because I'm involved in triaging/maintenance for user-facing
> desktop packages. Bug reports are not always accompanied by patches,
> and somewhat frequently come with the implication (or even an explicit
> demand) that the maintainer must stop whatever it is they are doing and
> fix the bug immediately.

Let me clarify the things I've said about the expectations we have of
maintainers on this point.  I don't think we do or should expect
anything at all of maintainers with regard to bugs that do not come with
patches, or that come with patches for which there is little indication
that much thought or testing has gone into them.

> In the case of init system integration, it isn't completely clear what
> the severity of "NM doesn't work with sysvinit" would be, and proponents
> of sysvinit might argue for critical because losing network connectivity
> effectively breaks the whole system in some cases, or serious because
> the package should be able to work without its non-mandatory dependencies.
> RC bugs are one of the few places where the project puts specific
> expectations on maintainers.
>
> Conversely, there's also a reasonable argument for important, normal
> or wishlist, because sysvinit is one of multiple options - but getting
> into an argument over bug severity is still getting into an argument,
> and for developers who don't enjoy conflict, takes significant "spoons"
> to deal with.

Good point.  Poor quality bug reports can be pretty easily ignored, but
we don't have a comparable approach for maintainers to take with regard
to severity wars.

>> We do not expect maintainers to maintain
>> an environment to test their package on ports architectures before
>> uploading, but we do expect them to apply patches provided by porters
>> who discover regressions.
>
> I don't think that's completely true. If a maintainer considers a
> proposed patch to be unsuitable, we normally 

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

[Simon McVittie]

On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
> The dependency issue is more challenging.

As I said earlier in the thread, if we don't want to overrule on the
logind dependency, then I don't think overruling on the init script
would make any sense (whereas overruling on the logind dependency but
not the init script maybe would - that would effectively mean we were
asking sysvinit users who want to use NM to find a way to maintain an
init script out-of-band).

However, I think it's still worth talking about the init script, because
most of what I'm saying is non-NM-specific.

> Participants in the thread who have argued on that side of the
> discussion seem to implicitly rely on the idea that a package maintainer
> is responsible for applying an equally high level of quality assurance
> to every file or feature in their package, as that which they would
> apply to its most basic or flagship features.

Ordinarily, perhaps yes. However, for whatever reason, people are
particularly emotionally attached to particular init systems (or perhaps
to the absence of systemd). We can see this here already: I don't think a
dependency on a particular httpd or email server would have been brought
to the technical committee asking for a maintainer to be overruled,
and it seems unlikely to have had participants describing a maintainer
declining an NMU as an outrage.

If NM's LSB init script was present, but stopped working - perhaps
because upstream deliberately made more use of systemd facilities, or
because upstream accidentally relied on systemd facilities due to none of
the upstream developers using anything else, or because the command-line
syntax changed and the upstream-provided systemd unit was updated but the
downstream init script wasn't - what do we expect to happen?

In the cases where the regression was accidental, ideally, the answer
would be someone calmly and politely offering a tested patch, but it
sadly seems equally likely to result in hostility, and I think it's
reasonable for a maintainer to try to avoid that preemptively by making
it clear that the LSB init script is someone else's responsibility.
Our volunteers are not automata, and I think maintainers need to be able
to set boundaries for their responsibilities to protect their mental state.

Similarly, in the case where the dependency is deliberate, I don't
think we want the responsibilities of a Debian maintainer to include
interceding between angry sysvinit users and upstream.

> We want maintainers to
> perform testing which is adequate to ensure that the core features of a
> package won't regress if they upload a new version, but we do not take
> maintainers to be responsible for testing every optional feature and we
> accept that such things might be temporarily broken until someone other
> than the maintainer can provide a patch.

I think perhaps you have higher expectations of bug reporters than I do
- perhaps because I'm involved in triaging/maintenance for user-facing
desktop packages. Bug reports are not always accompanied by patches,
and somewhat frequently come with the implication (or even an explicit
demand) that the maintainer must stop whatever it is they are doing and
fix the bug immediately.

In the case of init system integration, it isn't completely clear what
the severity of "NM doesn't work with sysvinit" would be, and proponents
of sysvinit might argue for critical because losing network connectivity
effectively breaks the whole system in some cases, or serious because
the package should be able to work without its non-mandatory dependencies.
RC bugs are one of the few places where the project puts specific
expectations on maintainers.

Conversely, there's also a reasonable argument for important, normal
or wishlist, because sysvinit is one of multiple options - but getting
into an argument over bug severity is still getting into an argument,
and for developers who don't enjoy conflict, takes significant "spoons"
to deal with.

For what it's worth, if we look at the results of GR 2019-002, and
ignore the winning option B because it did not specify the severity
of bugs about requiring a non-default init, we can see that option F
(non-default init support is wishlist) was voted ahead of options A
(non-default init support is important), D and H (non-default init support
is RC if a patch is available), and E (LSB init scripts are required,
presumably meaning RC). The design of our voting system is (meant to be)
such that we can draw conclusions from how options other than the winning
option were ranked, not just from the winning option vs. all the rest.

> We do not expect maintainers to maintain
> an environment to test their package on ports architectures before
> uploading, but we do expect them to apply patches provided by porters
> who discover regressions.

I don't think that's completely true. If a maintainer considers a
proposed patch to be unsuitable, we normally accept their judgement;
and if a proposed 

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

[Sean Whitton]

Hello Simon and others,

On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:

> If we are unable to use particular system services (in this case NM) with
> a particular non-default init system without putting extra responsibility
> on the maintainers of those system services, then I think that's a
> limitation of that init system that its maintainers could usefully
> address, and addressing that limitation would certainly be within the
> scope of exploring alternatives to systemd.

This is a good way to understand the notion of "exploring alternatives
to" systemd.  Thank you for explaining it.

I have not yet seen an argument which convinced me that asking the NM
maintainer to keep the init script in the package would actually be
putting extra responsibility on that maintainer, and this concerns me.

Participants in the thread who have argued on that side of the
discussion seem to implicitly rely on the idea that a package maintainer
is responsible for applying an equally high level of quality assurance
to every file or feature in their package, as that which they would
apply to its most basic or flagship features.  For example, it's been
suggested that requiring the NM maintainer to keep the file in the
package would mean that the NM maintainer would need to keep a sysvinit
system around to test that the init script still works before they could
upload a new version of NM.  I don't see why there would be any such
need.

Indeed, I don't think this is how we typically think of the
responsibilities of Debian package maintainers.  We want maintainers to
perform testing which is adequate to ensure that the core features of a
package won't regress if they upload a new version, but we do not take
maintainers to be responsible for testing every optional feature and we
accept that such things might be temporarily broken until someone other
than the maintainer can provide a patch.

In this case, I don't see how keeping the init script in the package
creates any expectations on the NM maintainer beyond applying patches to
the init script from those who have the relevant specialised knowledge.
A good analogy would be ports.  We do not expect maintainers to maintain
an environment to test their package on ports architectures before
uploading, but we do expect them to apply patches provided by porters
who discover regressions.  Why would our expectations be any greater in
this case?

Of course, if the script became seriously broken and was getting in the
way of a release or something like that, we would typically see it as
within the maintainer's prerogative to remove it.  Just as we would
accept a maintainer breaking compatibility with a port by reverting a
porter's patch if that was the only feasible way to meet a freeze
deadline, say.  But as has been pointed out, that's not the case we are
dealing with here.

I would like to see arguments that we would be imposing any extra
responsibility on the NM maintainer which do not rely on the idea that a
package maintainer is equally responsible for regressions anywhere in
their package, or, of course, an argument that I'm misunderstanding
what's being implicitly assumed.

The dependency issue is more challenging.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Mark Hindley]

Josh,

On Mon, Nov 30, 2020 at 04:24:28PM -0800, Josh Triplett wrote:
> If (hypothetically) network-manager upstream
> decided to remove those legacy fallbacks, the maintainer would then be
> in a position of either:

But that is not what this particular discussion is about. Personally, I have no
interest in rehearsing the GR discussions again. Maybe there are cases where
removal of a broken initscript could be justified. However, this is about the
removal of a functioning initscript. It is the removal itself that causes the
breakage to some people's systems.

If the NM maintainer could point to an upstream change that necessitated the
removal of the initscript then I would not have opened #964139 in the first
place. However, such evidence has not been forthcoming.

If the NM maintainer could point to a breakage caused by adding support for
libpam-elogind as mandated by the winning GR resolution, I am pretty sure that
we would not be seeking resolution via the tech-ctte now. Again, I am unaware of
any such breakage.

Best wishes.

Mark

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

[Josh Triplett]

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?

[Matthew Vernon]

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?

[Mark Hindley]

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

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

[Simon McVittie]

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.

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

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

[Simon McVittie]

On Sat, 21 Nov 2020 at 10:47:17 +0200, Wouter Verhelst wrote:
> On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> > 1) poor user experience - a package of initscripts would clutter
> > /etc/init.d/ with a huge number of files (most of which would be no use to
> > the user)
>
> This could be fairly easily fixed.
> 
> Option one:
> - Don't install the init scripts in /etc/init.d, but install them in
>   /usr/share somewhere.
> - Install a dpkg trigger that uses ucf to copy the relevant init scripts
>   /etc/init.d (and goes through the rest of the dance to enable them)
>   when the relevant package(s) is/are installed.

Or someone could teach sysv-rc or insserv to look for init scripts in
/usr/share/init.d, with an init script in /etc/init.d of the same name
taking precedence; or the init script in /etc/init.d could be a symlink
to one in /usr/share by default, with the sysadmin able to replace it with
a regular file if they want to modify it; or something along those lines.
I'm sure people who prefer to use LSB init scripts can work something out.

It occurs to me that something along these lines would largely solve one
of the ongoing design issues with LSB init scripts (and cron jobs, and
other interfaces based on dropping an arbitrary executable script into a
designated place in /etc): the fact that they are conffiles, and therefore
remain in /etc when their package is removed but not purged. This can
break other related or unrelated packages if the script is not correctly
guarded by "if [ -x /usr/sbin/something-relevant ]", and is difficult
to fix reliably with a package update: script maintainers can of course
fix their script to have that guard at any time, but users affected by
the bug will not receive the fixed script, because the script's package
is no longer installed and so will never be upgraded to a fixed version.

I think I've seen several occasions on which an obsolete init script
(or cron job or hook or other integration script) remaining on the system
triggered RC bugs during upgrade, leading to some related package having
to have (non-Policy-compliant!) glue code to remove or otherwise defang
the integration script so that the upgrade could proceed.

Having that guard also means the script still has to be executed in
order to figure out that it doesn't need to do anything, which is a
shell invocation that didn't need to happen.

Now, this is clearly not the way LSB init scripts have traditionally
worked in Debian. However, I note that the winning option in GR 2019-002
says we will "support exploring alternatives". It does not say that we
will preserve sysvinit, LSB init scripts and sysv-rc in precisely the way
they have traditionally worked in Debian - after a couple of decades I
would hope that we have already adequately explored sysv-rc, and have
a reasonably clear picture of its advantages and disadvantages. If
people want to continue to use it, addressing or mitigating the
disadvantages seems like part of the task of maintaining it and keeping
it fit-for-purpose.

> This puts the burden of maintaining said init script on the maintainer.
> In my reading of the GR, that's not expected of maintainers anymore.
> 
> I think it's fair for a maintainer to be expected to file a bug on an
> "init scripts" package if their CLI changes. The rest should then be the
> job of the maintainers of that init scripts package.

That's my understanding too, and Wouter's mail continues by making good
points about this topic.

If we are unable to use particular system services (in this case NM) with
a particular non-default init system without putting extra responsibility
on the maintainers of those system services, then I think that's a
limitation of that init system that its maintainers could usefully
address, and addressing that limitation would certainly be within the
scope of exploring alternatives to systemd.

smcv

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

[Simon McVittie]

On Thu, 19 Nov 2020 at 21:04:00 -0800, Elana Hashman wrote:
> It would be much appreciated if Michael Biebl or another maintainer from
> the Utopia team could add some context here.

Most of the people in the pkg-utopia team are not active contributors to
most of its packages, so I don't think soliciting comment from members of
the pkg-utopia team is necessarily going to be particularly enlightening.
Looking at the Uploaders and commit history, Michael is very much the
primary maintainer of NetworkManager and its adjacent packages.

I am technically a member of that team myself, but I don't feel that I
can comment on Michael's decisions or the reasons for them, and the one
time I contributed a patch to NM, I behaved the same way I would have
done for an entirely unrelated package. The "utopia" name is a relic of
the team's origins in packaging "Project Utopia", a loose umbrella for
projects aiming to improve device management and hotplugging in Linux
generally and GNOME specifically, most of which were subsequently
superseded (in particular HAL, the central Project Utopia package,
which was replaced by udev improvements for the lower-level parts and
multiple more-focused higher-level projects like upower, udisks and
arguably parts of systemd for the higher-level parts).

If the utopia team didn't already exist and a team was needed for what it
maintains, it would probably be the freedesktop team (which also exists,
with a significant overlap in membership).

smcv

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

[Simon McVittie]

On Thu, 19 Nov 2020 at 11:40:20 +, Ian Jackson wrote:
> My view is
> that the behaviour seen in #921012 and #964139 is an outrage

I don't think this is constructive, and if a package's maintainer doesn't
want to enter into conversations, this doesn't seem like an approach
that will change their mind.

Matthew opened this thread with a message that focused on technical points
and avoided emotive language, and I would like to keep the discussion on
that basis. The technical committee's responsibility is to make decisions
on their technical merits, and I'm sure you don't think that we are or
should be more likely to take your side because you have expressed outrage.

If you feel that the community team or DAM needs to be involved, they're
available to be contacted (perhaps they have been already), but this
pseudo-package is not their issue tracker and this bug is not theirs
to resolve.

Thanks,
smcv

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

[Simon McVittie]

Some procedural points, without going into the merits of the technical
committee doing as you ask or not:

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?

This is clearly something that the technical committee is empowered to
do, if we choose to do so (which requires a 3:1 majority in favour of
overruling the maintainer).

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

If what you want on a relatively short timescale is for the maintainer
of network-manager to be overruled, and the timing is important to you
because of the imminent bullseye freeze, then I would suggest that it
might be more expedient to turn this tech-ctte bug report into a request
to overrule the network-manager maintainer, and put aside the broader point
for now. If that's the case, retitling it to something more like

tech-ctte: Overrule network-manager maintainer to apply non-systemd init 
patches

would seem appropriate.

As Josh has said elsewhere in the thread, we can give advice (6.1.6),
we can decide matters of technical policy (6.1.1), and we can tie-break
on technical matters where developers' jurisdictions overlap (6.1.2);
but we cannot overrule the views of Debian's membership as a whole, as
expressed by GRs. Elsewhere in this thread there has been some dispute
over whether it is the TC's place to make this resolution. If we can
stop thinking about that question, then it seems to me that we are more
likely to be able to answer the other request on the timescale you need.

Obviously, when we decide to overrule or not overrule the network-manager
maintainer, that can certainly give maintainers of other packages
in a similar position a hint as to what the likely outcome would be
if there was a request to overrule *them* - but different packages'
circumstances are different, so our decision would not necessarily always
go the same way.

For example, if the maintainers of dbus and gnome-initial-setup chose
to make them depend on systemd and you asked the technical committee to
overrule both decisions, I suspect we would be more likely to overrule
on dbus (because losing dbus would make a lot of packages, uses and
high-level features unavailable to those who want to experiment with
other init systems), and less likely to overrule on gnome-initial-setup
(because that's just one feature).

(With dbus maintainer hat on, I do not intend to remove its LSB init
script, and I certainly don't intend to remove the init script and then
use TC powers to require myself to put it back! :-) It's just an example
of a package for which losing non-systemd init support would have a wider
impact on users of non-systemd init.)

smcv

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

[Simon McVittie]

On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote:
> I don't think this is very common. Init scripts are very specific to a
> distribution. A Debian init script cannot be used for Redhat. A SUSE
> init script does not work with Redhat. I find doubtful that the
> compatibility would be better with the BSD init scripts (this may not be
> what you meaned). AFAIK, OpenBSD does not use initscripts. A FreeBSD
> initscript is unlikely to work on any Linux as it sources /etc/rc.subr.
> 
> From my experience, when upstream ships an init script, this is usually
> unsable by most distributions (not to the standard), so it has to be
> rewritten. Init scripts are not contributed upstream as upstream doesn't
> want to handle all this complexity.

For what it's worth, as an upstream and Debian maintainer of dbus, I
removed the LSB-style init scripts for Red Hat and Slackware from the
upstream source code of dbus, because nobody was testing them and so I
had no confidence that they continued to work (Red Hat moved to Upstart
and then to systemd, and Slackware used their own init script instead
of the one provided upstream, so the relevant downstreams were not even
using the versions that were part of dbus stable releases, and they
certainly weren't testing development releases).

dbus in Debian continues to have a LSB init script that was never sent
upstream; Debian is better-placed to maintain that than upstream is (even
though at the moment it would be me making changes either way!), and it
can continue to take advantage of Debianisms like start-stop-daemon.

The LSB/sysv-rc interface (execute arbitrary code, which is going to be
a lot simpler if it relies on distro-specific facilities like
start-stop-daemon) does not really lend itself to writing portable init
scripts. The few portable init scripts that I have seen have generally
had robustness issues, precisely because they bend over backwards to
avoid using distro-specific facilities.

Echoing what Vincent said, my experience has been that systemd units *can*
typically be used unmodified across distributions - partly because they
are declarative, partly because the upstream part of systemd provides
facilities to do typical system service things without having to open-code
them or rely on a helper like start-stop-daemon (for example tracking
lifetime, dropping privileges, and sending SIGTERM to terminate gracefully
or SIGHUP to reload), and partly because the "drop-in" mechanism gives
us a way to add distro overrides where needed without necessarily having
to patch the unit.

smcv

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

[Vincent Bernat]

 ❦ 19 novembre 2020 09:04 GMT, Matthew Vernon:

> 3) many upstreams (esp. those who support BSD) ship a sysvinit file,
> again making the daemon (source at least) package the natural place to 
> keep it.

I don't think this is very common. Init scripts are very specific to a
distribution. A Debian init script cannot be used for Redhat. A SUSE
init script does not work with Redhat. I find doubtful that the
compatibility would be better with the BSD init scripts (this may not be
what you meaned). AFAIK, OpenBSD does not use initscripts. A FreeBSD
initscript is unlikely to work on any Linux as it sources /etc/rc.subr.

>From my experience, when upstream ships an init script, this is usually
unsable by most distributions (not to the standard), so it has to be
rewritten. Init scripts are not contributed upstream as upstream doesn't
want to handle all this complexity.

This is in contrast with systemd service files, which are more likely to
work on various Linux distributions.
-- 
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Wouter Verhelst]

On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> [I don't need a CC, thanks]
> Hi,
> 
> > 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 have thought about this, and it seems like a bad idea for a number of
> reasons, including:
> 
> 1) poor user experience - a package of initscripts would clutter
> /etc/init.d/ with a huge number of files (most of which would be no use to
> the user)

This could be fairly easily fixed.

Option one:
- Don't install the init scripts in /etc/init.d, but install them in
  /usr/share somewhere.
- Install a dpkg trigger that uses ucf to copy the relevant init scripts
  /etc/init.d (and goes through the rest of the dance to enable them)
  when the relevant package(s) is/are installed.
Option two: split up the initscripts package into multiple smaller
packages.

I don't think either of these are necessary, but if it's a concern,
there are ways.

> 2) init scripts to need to change sometimes, typically that change will
> accompany a version change in the associated daemon (e.g. the CLI changes) -
> the most natural way to have this work seamlessly is for the init script to
> come with the daemon

This puts the burden of maintaining said init script on the maintainer.
In my reading of the GR, that's not expected of maintainers anymore.

I think it's fair for a maintainer to be expected to file a bug on an
"init scripts" package if their CLI changes. The rest should then be the
job of the maintainers of that init scripts package.

> 3) many upstreams (esp. those who support BSD) ship a sysvinit file, again
> making the daemon (source at least) package the natural place to keep it.

Yes, but does this also apply to network manager?

> 4) difficulty reliably achieving seamless handoff from daemon package to a
> putative sysvinit-scripts package (e.g. packages that actively remove the
> init.d file from the installed system; keeping a users' modifications to the
> file)

This might need some dependency trickery that I don't immediately have a
good answer for, but that I don't see as insurmountable.

Furthermore, it is my belief that if you are not running the default
init system, that then *some* level of ugliness is to be expected. At
the very least, you'd see systemd units on the file system that you're
not ever going to be using. I think it's unreasonable to expect the same
level of cleanliness and technical excellence as when your preferred
init system was still the Debian default.

> > 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.
> 
> I think the burden concern is over-made here. This is not a case of "this
> init script has bugs that have been causing problems and no-one has fixed
> it", nor a bug report of the form "please write an init script". There is an
> extant, working init script.

Software changes. Environments change. Sometimes an init script stops
working due to changes outside the maintainer's area of responsibility.
This has happened to the nbd-client init script at one point, for
example (no bug, because I found it out myself and fixed it, but it did
happen).

Thus, maintaining an init script that the maintainer themselves doesn't
want to use or think is useful, imposes a burden of *at least* testing
it on the maintainer, for which they need a separate system (or, at
least, a VM) in order to do proper testing of the package with all that
implies. That's actually quite a bit of work, and it's not unfair that
the maintainer wouldn't want to do it.

If the init script is in the network-manager package, then the
maintainer is at the very least *expected* to make sure it keeps
working. If it stops working, where is the maintainer going to ask for
help? There is no guaranteed answer for the maintainer, and nothing they
can do other than accept bugs against their package that they then have
to set up a wholly separate system for just so they can fix a bug they
don't want to deal with in the first place.

If the init script is in a separate package, then the maintainer can
certainly give a heads-up to the maintainers of the separate package
when something changes in network-manager. It would not be unreasonable
to expect the network-manager maintainer to maintain a level of
communication with the maintainers of said initscripts package, and I
think you would have a *much* stronger case for complaining about
maintainers not wanting to support your pet project.

> There are people more than happy to provide assistance should it need
> updating. I concede that collaborating with those people is non-zero
> effort, 

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

[Elana Hashman]

On Thu, Nov 19, 2020 at 04:20:46PM -0800, Tianon Gravi wrote:
> 
> On Wed, 18 Nov 2020 at 23:33, Josh Triplett  wrote:
> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> > Even if someone else offers to shoulder some of that load, that does not
> > eliminate the maintenance burden; in some cases, it may not even reduce
> > the maintenance burden.
> 
> Thank you for this.  This puts into very straightforward words a
> feeling I've had for ages but couldn't word well.
> 
> In many projects I maintain outside Debian, I very frequently see this
> belief that if someone else contributes the work to make something
> possible (or it is otherwise perceived as "trivial" work), that
> there's no work for the maintainer, when it actually *does* increase
> the maintenance burden, often in ways the contributor cannot or will
> not see (or in some extreme cases, refuses to).

I caution folks from speculating too much on the maintainer's
motivations and reasoning while they haven't yet had a chance to share
their perspective on the bug. :)

From what I can see reading through both #964139 and #960780, no
technical rationale has been given for why the script was removed, only
a statement that the removal was intentional.[0]

It would be much appreciated if Michael Biebl or another maintainer from
the Utopia team could add some context here.

- e

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139#62


signature.asc
Description: PGP signature

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

[Tianon Gravi]

(Going to leave my own opinions on the underlying discussion here
aside, but wanted to highlight/echo this bit:)

On Wed, 18 Nov 2020 at 23:33, Josh Triplett  wrote:
> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that package.
> Even if someone else offers to shoulder some of that load, that does not
> eliminate the maintenance burden; in some cases, it may not even reduce
> the maintenance burden.

Thank you for this.  This puts into very straightforward words a
feeling I've had for ages but couldn't word well.

In many projects I maintain outside Debian, I very frequently see this
belief that if someone else contributes the work to make something
possible (or it is otherwise perceived as "trivial" work), that
there's no work for the maintainer, when it actually *does* increase
the maintenance burden, often in ways the contributor cannot or will
not see (or in some extreme cases, refuses to).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

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

[Josh Triplett]

On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton  
wrote:
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > 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.
[...]
> In our dispute resolution role, the TC is empowered to decide upon the
> two things about the contents of the network-manager package that we
> have been asked to decide upon, as a matter of last resort.  No-one
> disputes that we can do this.

(I agree with this paragraph, in case there was any doubt about that.)

> We have also been invited to rule that "Similar init-compatibility
> changes should not be blocked by package maintainers unless they are
> defective on their own merits".  Essentially we are being invited to
> generalise the decision that we make about the network-manager package
> to say that it would apply to similar cases.
> 
> We might decide that the reasons we have for whatever decision we make
> about the network-manager package do not generalise, and so we may
> decline the invitation to make any more general ruling.
> 
> But if we do think the reasons generalise, then we can generalise our
> ruling without stepping outside of our dispute resolution role.  For
> example, we might say "if another CTTE bug was filed about the contents
> of a package which was similar to this one in the following respects
> ... then we would expect to issue the same ruling as we have here,
> because we believe that our reasons for this ruling would apply to all
> packages which are similar in the previously stated respects."
> 
> Clearly we would not want to say anything which we thought contravened
> the GR.  However, I do not think there is any reason to think that
> resolving this dispute would necessarily involve the TC interacting with
> the GR in a way that the constitution does not permit.  We are being
> asked to decide about one package, and being invited to generalise in a
> way that falls within the scope of our dispute resolution role.

It would certainly be *possible* for the TC to suggest that it would
systematically rule in favor of, to use these two issues as examples,
including init scripts and alternative dependencies despite the
maintainer not wishing to maintain them. What I'm suggesting is that,
given that the slate of GR options included possibilities that would
have required maintainers to do so by policy, and the developers
declined to enact such a policy, it would be *especially* unfortunate if
the common practice became to either systematically escalate to the TC
or use the threat of such to effectively enforce a different policy.

The GR encouraged people on all sides to collaborate in this area, not
to pick a side and do everything possible to undermine the other side.
It seems as though the current path thus far has been to present one
option, and when that option was declined, seek enforcement from the 

Bug#975075:

[Josh Triplett]

[I have consolidated responses to multiple bits of quoted text here, in
an effort to consolidate responses to variations on the same points, in
the hopes that doing so will avoid proliferating variations on a common
theme.

Also, the title of this bug itself presumes a disputed point of view.]

On Thu, 19 Nov 2020 11:40:20 + Ian Jackson 
 wrote:
> Josh Triplett writes:
> > I do not believe it falls within the scope of the technical
> > committee to override a decision already decided by a project-wide
> > GR,
> 
> No-one is asking the TC to override the GR.  In fact, Matthew is
> asking the TC to *implement* the GR.

> > 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,
> 
> I think that was the aim of the proponent.  Unfortunately, the winning
> option did not support that desire.

That is an adverse interpretation that I do not believe is supported by
either the text of the GR or the intentions of those voting for it.

I would also like to make the observation that, both during the voting
for the GR *and* shortly after the GR, people opposed to this GR
repeatedly stated that the winning option would allow package
maintainers to decline to support alternative init systems if they did
not wish to support a proposed change; some of those opposed to this GR
outcome even suggested that it would make systemd effectively mandatory.
(This has not turned out to be the case, in practice.) I find it
interesting that that was the stated interpretation used to oppose the
GR and subsequently bemoan the outcome, but yet now an alternative
interpretation surfaces that would paint the outcome as though there
were a *mandate* for maintainers to always support alternative init
systems.

To be clear: I don't believe the intent of the GR was for all package
maintainers to *systematically* remove init scripts or alternative init
support, and I don't believe that's what happened here. If I believed
that there was some ill intent here to destroy alternative init systems
(rather than simply a desire to avoid expending time and energy on
them), I would not look favorably on that. I also don't believe that the
intent of the GR was to *force* maintainers to merge alternative init
support. Given the evident desire of some package maintainers to avoid
expending effort in ongoing maintenance of support for alternative init
systems, it would have been desirable to seek alternatives that remove
that burden from the package maintainer, and shift it to those working
on alternative init systems. Instead, it appears that the moment a
package maintainer declined the solution that would be the least work
for those working on alternative init systems, the matter was escalated
to the TC rather than seeking alternatives.

To the extent the TC wishes to solve the more general problem rather
than the specific case, I would propose that honoring the intent of the
GR would be to request potential solutions that appropriately
compartmentalize the work of maintaining alterntive init support to
remove it entirely from the package maintainer. The TC does not do
detailed design work to generate alternatives that were not put before
it, but it would certainly be within the remit of the TC to request that
others do so, and to evaluate such alternatives if a consensus cannot be
reached. But as far as I can tell, there was *no* apparent effort to
propose any such alternatives; the matter was simply taken to the TC
once the first proposal was declined.

This is *not* as simple as "just merge the init script and Depends
change". It has also included other ongoing work each time a new
compatibility issue arises. Past evidence suggests that this has proven
to be a source of ongoing maintainer burden, despite claims to the
contrary.

> > 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.
> 
> Obviously the TC ought not to undermine the GR.  What counts as
> undermining the GR and what counts as implementing appears to be a
> matter of debate.

So it would unfortunately seem. One would have hoped we were all debated
out after the GR, and that the GR could stand as evidence of the outcome
of that debate.

As stated in my previous mail, the *least* favored option in the GR vote
was "Further Discussion", and yet here we are, having Further
Discussion.

> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> 
> This is true of course.  But that is the key role of the maintainer.
> As recognised in the GR text.

The maintainer is also empowered to decide whether or not to include any
given change, if they deem the cost/benefit tradeoff inappropriate.

> > The GR encouraged developers to work with each other; it did not
> > *mandate* 

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

[Josh Triplett]

On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton  
wrote:
> Hello,
> 
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > I'd also like to address one other issue here. It would be easy to
> > hypothesize, at this point, that some additional communication (or more
> > verbose communication) from the maintainer might have helped here.
> > However, I would express doubt that any more verbose version of "no"
> > (e.g. a long-form explanation about undesired additional maintenance
> > burden) would have led to any less escalation. I think the situation
> > would still have ended up here, no matter how much time or energy was
> > expended in writing responses.
> >
> > That seems particularly likely given the adversarial NMU directly
> > attempting to override an active package maintainer's decision, which
> > escalated the situation further. (Such adversarial NMUs have occurred in
> > regard to alternative init support in the past, as well.) And I don't
> > think anyone can reasonably suggest that they thought the change was
> > made unintentionally (given that it was explicitly mentioned in the
> > changelog), which makes the NMU a rather hostile escalation.
> >
> > I would ask anyone on the TC who feels that more verbose answers were
> > desirable whether they think a more verbose answer would have had any
> > effect on the outcome or subsequent escalations.
> 
> Assuming for a moment that the TC does not decline to rule, it is going
> to be very hard for us to make a good decision if we lack more detailed
> input from the package maintainer.

I'm not suggesting otherwise; I'm only asking the TC to refrain from
suggesting that further communication alone, prior to this point, would
have averted this situation. The original request makes such
implications, so they may potentially have formed part of what the TC
ruled on. (The TC does sometimes issue similar suggestions as part of
its rulings, in what I think is generally a *good* practice of
encouraging people to work things out and giving them guidance on how to
do so.)

> We can speculate as to whether the dispute would have proceeded better
> or worse with more verbose messages from Michael before now, but it
> would be beside the point.

Thank you; that fully addresses this particular point.

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

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

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

I have been thinking about this procedural issue and in the end I think
that it is moot.  Let me explain how things seem to me.

In our dispute resolution role, the TC is empowered to decide upon the
two things about the contents of the network-manager package that we
have been asked to decide upon, as a matter of last resort.  No-one
disputes that we can do this.

We have also been invited to rule that "Similar init-compatibility
changes should not be blocked by package maintainers unless they are
defective on their own merits".  Essentially we are being invited to
generalise the decision that we make about the network-manager package
to say that it would apply to similar cases.

We might decide that the reasons we have for whatever decision we make
about the network-manager package do not generalise, and so we may
decline the invitation to make any more general ruling.

But if we do think the reasons generalise, then we can generalise our
ruling without stepping outside of our dispute resolution role.  For
example, we might say "if another CTTE bug was filed about the contents
of a package which was similar to this one in the following respects
... then we would expect to issue the same ruling as we have here,
because we believe that our reasons for this ruling would apply to all
packages which are similar in the previously stated respects."

Clearly we would not want to say anything which we thought contravened
the GR.  However, I do not think there is any reason to think that
resolving this dispute would necessarily involve the TC interacting with
the GR in a way that the constitution does not permit.  We are being
asked to decide about one package, and being invited to generalise in a
way that falls within the scope of our dispute resolution role.

-- 
Sean Whitton

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

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton

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

[Felix Lechner]

Hi,

On Wed, Nov 18, 2020 at 11:33 PM Josh Triplett  wrote:
>
> I do not believe it falls within the scope of the technical committee
> to override a decision already decided by a project-wide GR

In the State of California we follow such a strict interpretation of
ballot measures. While consistent with direct democracy, it is also
widely blamed for a dysfunctional state government. [1] But even here,
courts enjoy some leeway.

Please consider Proposition 8. Widely publicized in 2008, it was a
successful ballot initiative that banned same-sex marriage by amending
the state constitution (yes, California can be conservative). A
Federal District Court later ordered the State to ignore the people.
While the appeals failed on narrow grounds, the original opinion that
ended up standing was described as ruling that "the amendment was
unconstitutional under both the Due Process and Equal Protection
Clauses of the Fourteenth Amendment, since it removed rights from a
disfavored class with no rational basis." [2]

In Debian, users of 'sysvinit' strike me as such a "disfavored class".
Personally, I find it outdated and would never use it again, yet based
on how often the topic reappears, there are clearly people who think
differently. Now similarly to Proposition 8, I believe the GR should
bind the DPL and all delegates—but not the Technical Committee. It is
our supreme court.

Like Josh's message, I make a point of procedure. The Technical
Committee should be free to rule. They could also decline, for example
by citing the GR.

As an aside, the Debian Constitution lacks any elevating language that
by itself would make such daring projections of universal justice
possible. In fact, our constitution mentions no "rights" whatsoever
(except for a copyright notice at the bottom). That is why I had to
resort to an outside precedent to make my point. The constitution's
text also leads me to renew my call: Let's rewrite Debian's
foundational documents together to promulgate inspiring ideals we can
hold up in the sky.

[1] https://openlibrary.org/works/OL16420003W/California_crackup
[2] https://guides.ll.georgetown.edu/c.php?g=592919=4182204
[3] https://lists.debian.org/debian-devel/2014/11/msg00174.html

Kind regards,
Felix Lechner

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

[Ian Jackson]

1. Basic principles

Josh Triplett writes:
> I do not believe it falls within the scope of the technical
> committee to override a decision already decided by a project-wide
> GR,

No-one is asking the TC to override the GR.  In fact, Matthew is
asking the TC to *implement* the 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.

Obviously the TC ought not to undermine the GR.  What counts as
undermining the GR and what counts as implementing appears to be a
matter of debate.

> Thus, I would suggest that the technical committee should decline to
> rule on any matters already decided by the GR.

On the contrary, if the GR is to be effective, it must be honoured.
That means that if an individual maintainer or contributor does not
respect the GR decision, the decision should be enforced by the
project's existing governance mechanisms.


2. Misrepresentation of the GR decision substance

> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that package.

This is true of course.  But that is the key role of the maintainer.
As recognised in the GR text.

> The GR encouraged developers to work with each other; it did not
> *mandate* developers to spend their time and energy supporting
> alternative init systems,

This is quite simply false.  End of 2nd para of the winning option:

 | It is important that the project support the efforts of developers
 | working on such technologies where there is overlap between these
 | technologies and the rest of the project, for example by reviewing
 | patches and participating in discussions in a timely manner. 

This TC bug is precisely about such a situation.  As Matthew explains
in his most recent mail, the provision of init scripts is precisely
such a situation, where by fasr the most practical way to deal with
"such technologies" (init scripts) is to acknolwedge the "overlap with
the rest of the project" (by putting the scripts in the packages for
the daemons).

That the dispute is about "overlap" is even more true about #921012,
which is about a Depends.


3. Analysis of the winning vs non-winning options

Josh looks at some of the non-winning options, and uses the fact that
those non-winning options were defeated as arguments *against* their
contents.  Our voting system is specifically set up to allow multiple
different variations on a theme, so this is not a valid approach.

> The GR contained options for requiring ("must"), or even strongly
> encouraging ("should"/"important"), developers to maintain sysvinit
> support; those options did not win.

It also contained a non-winning option (F) making it clear that bugs
like #921012 and #964139 would be treated as wishlist.

> The bug did in fact have input from the maintainer, the day it was
> filed: it was tagged as wishlist.

Indeed, the maintainer is behaving as if option F had won.


4. Purpose of the GR, and overall intent of the winning option

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

I think that was the aim of the proponent.  Unfortunately, the winning
option did not support that desire.

Having spoken to a number of people both before after the vote I have
the impression that the Developers as a whole were not keen on a long
text which explicitly dealt with various matters in dispute and were
fed up of being asked these kind of questions in GRs and hoped the
project could behave like grown-ups.  Sadly this seems to have been
over-optimistic.


5. Role of the TC

Josh disputes that the TC has an appropriate role here, asserting the
GR has pre-empted the TC's role.  However:

 | Maintainers use their normal procedures for deciding which patches
 | to include.

The TC is explicitly empowered to exercise the maintainer's
decisionmaking authority, via its power to overrule a maintainer
decision.

Furthermore, the TC can clearly make its opinion known.  My view is
that the behaviour seen in #921012 and #964139 is an outrage which
ought to result in DAM action.  It would be open to the TC to make a
statement strongly criticising the maintainer's behaviour and
suggesting that the Community Team and/or DAM ought to intervene.


Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

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

[Matthew Vernon]

[I don't need a CC, thanks]
Hi,


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 have thought about this, and it seems like a bad idea for a number of 
reasons, including:


1) poor user experience - a package of initscripts would clutter 
/etc/init.d/ with a huge number of files (most of which would be no use 
to the user)


2) init scripts to need to change sometimes, typically that change will 
accompany a version change in the associated daemon (e.g. the CLI 
changes) - the most natural way to have this work seamlessly is for the 
init script to come with the daemon


3) many upstreams (esp. those who support BSD) ship a sysvinit file, 
again making the daemon (source at least) package the natural place to 
keep it.


4) difficulty reliably achieving seamless handoff from daemon package to 
a putative sysvinit-scripts package (e.g. packages that actively remove 
the init.d file from the installed system; keeping a users' 
modifications to the file)



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.


I think the burden concern is over-made here. This is not a case of 
"this init script has bugs that have been causing problems and no-one 
has fixed it", nor a bug report of the form "please write an init 
script". There is an extant, working init script. There are people more 
than happy to provide assistance should it need updating. I concede that 
collaborating with those people is non-zero effort, but this is not a 
case of "I want this work done and am not prepared to help do it".


Regards,

Matthew

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

[Josh Triplett]

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?

[Philipp Kern]

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?

[Felix Lechner]

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