Your message dated Wed, 17 Mar 2021 18:03:09 +0100
with message-id <dd22dbadb7d678056356aa5954114...@debian.org>
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 users and maintainers to
communicate openly and try to find compromise solutions like this one.

Thanks,
Marga on behalf of the Technical Committee

--- End Message ---

Reply via email to