
Debian network-manager: Please restore removed init script - grifferz
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139
======
grifferz
I submitted this as being interesting because I feel it is a turning point in
Debian's long init wars.

The most recent Debian General Resolution on init support said something like
"we chose systemd but compatibility with other inits is important"

It did not clarify whether a package maintainer was allowed to remove working
SysV init support and refuse to add it back, and this is now what is happening
here, so I think the end result of this will set a precedent within Debian
that the vote did not.

The package maintainer has remained quiet on their reasons other than "this is
intentional", which again might be interesting because it might speak to
whether the maintainer needs to defend their choices at all.

In a hypothetical situation, if an upstream piece of software specifically
states that it doesn't support non-systemd systems then I could see how a
maintainer might want to remove previously-contributed support for being a
burden on future maintenance. I am not saying this is the case here, I am just
saying this could be a possible argument for why it's not a black and white
matter.

In Debian package maintainers have a lot of leeway on what goes on within
their packages. In other Linux distributions there are often more centralised
groups who would make such a decision ahead of time as a broad project goal.

In Debian these decisions can get referred to the technical committee but that
is often considered "the nuclear option".

~~~
capableweb
Worth clarifying, only to be precise:

"Systemd but we support exploring alternatives" was what was said in the GR
(Choice B in
[https://www.debian.org/vote/2019/vote_002](https://www.debian.org/vote/2019/vote_002))

So while alternatives could be supported, I guess it's up to the maintainer to
decide if these chose to do so. In this case, the maintainer didn't want to,
but could of course provide some better argument than "I didn't feel like it
and it wasn't a mistake".

~~~
rleigh
> "I guess it's up to the maintainer"

When you have a high-level direction set by the organisation, you can't have
it arbitrarily overridden by individuals with no discussion and no
justification. This permits individuals who act against the overall interests
of the organisation in persuit of their own agendas to dictate its path simply
by being obstructive or contrary. This is not being a team player, or in fact
playing fair at all.

~~~
capableweb
Well, to be fair, the guideline ended up being A) Support systemd and B)
Explore alternatives if you want to. In this case, the author chose to do A
and not B. That's following the high-level direction and not overriding
anything.

~~~
rleigh
I don't believe it is following the high-level direction at all. It's
completely counter to it.

Dropping existing working support is deliberately and intentionally stopping
alternatives from working. Refusing to consider help from others to maintain
this support is deliberately and intentionally preventing alternatives from
being supported.

~~~
capableweb
Seems you're right, according to
[https://news.ycombinator.com/item?id=24493214](https://news.ycombinator.com/item?id=24493214)
(and [https://bugs.debian.org/746715](https://bugs.debian.org/746715)) which
states "That includes merging reasonable contributions, and not reverting
existing support without a compelling reason" which I missed when first
reading about it. Thanks :)

------
JdeBP
Here's the commit. Unfortunately, there is no explanation in the commit
message. Notice that it touches more than the van Smoorenburg rc script.

* [https://salsa.debian.org/utopia-team/network-manager/-/commi...](https://salsa.debian.org/utopia-team/network-manager/-/commit/588ae1fa93a571b7da8f969052e5fd957e65e8c8)

Michael Biebl, for those unfamiliar with Debian, is one of the maintainers of
the network-manager Debian package and of the systemd Debian package, amongst
a number of others; and also a contributor to systemd itself.

* [https://qa.debian.org/developer.php?email=biebl%40debian.org](https://qa.debian.org/developer.php?email=biebl%40debian.org)

* [https://github.com/systemd/systemd/commits?author=mbiebl](https://github.com/systemd/systemd/commits?author=mbiebl)

------
salawat
And this is why, I won't touch Debian anymore. I get enough BS politics and
fief building to deal with elsewhere, and if I really want a Debian package,
I'll pop the .deb open, and adopt it to my system conventions.

I'm not sold on Debian's "maintainer knows best" attitude. You are not there
to make decisions for the community, you are there to ensure the tools people
use and want maintained are.

As soon as you lose sight of the "servant" mentality when sitting in a
position of authority is about the time a defenestration is in order. The
attitude of the maintainer in light of the obvious interest in that feature in
that thread, the GR last year, and the lack of any justification whatsoever on
the technical merits of the fix, combined with the gall of asserting the
project is maintained is ridiculous. I'm legit angry now. If you can't be
arsed to do your job, then stop. Stop detracting from the addition of code
required to adapt something to work for a wider user base without good
contextual justification, which was not provided.

~~~
tremon
Fully agreed. There was a time when Debian could pride itself on being "the
universal operating system" (for whatever interpretation of that phrase), but
too many maintainers seem to have adopted a "my way or the highway" approach
to package maintenance. The systemd adoption was a catalyst in that direction,
but it wasn't the first nor the only symptom.

------
dangoljames
This whole argument is a bullshit argument. I have, somewhat grudgungly I'd
admit -- slowly come around to the idea that systemd might be worth the
trouble. That said, there is room for more than one working configuration
pattern, especially provided those patterns provide non-redundant featuresets
to their respective configurations.

The last point of bitterness for me with this entire issue is the entirely
uneccesary contention and strife with continuing to include sysV init. It's
loved by many and used by many, just leave it alone and let the users patch
it.

------
anned20
How the maintainer handles the bug report is weird too, childish even. Not
wanting to explain his reasoning and just ignoring it until it's absolutely
necessary to do so.

------
unethical_ban
In an internal org, this kind of attitude would be escalated to management. A
responsible party for software used by the public doesn't get to say "Because
I said so".

inb4 "technically yes they do" \- I'm talking about expectation, not
capability.

------
kps
This submission no longer appears at all in the 468 submissions reachable from
the front page and ‘More’, but it is not marked [dead] or [flagged].

------
roenxi
Crikey; filing an NMU without any particular notice is not the act of someone
trying to keep the peace. I'm no expert in Debian policy but surely the good
form approach is to submit the patch to the bug report and give the maintainer
a week to think about it.

I'd love to see SysV init support continued, but that NMU request isn't
helping. Maybe try harder with the negotiating first. There could be context
outside the bug report, but hostile maintenance is not the path to take. 4
people complaining in a bug report is no quorum for overruling the package
maintainer either.

~~~
grifferz
> Maybe try harder with the negotiating first.

If you read the bug report there is a period of about 7 weeks where they are
asking the maintainer why it was removed, offering to fix it, pointing out
that it works fine and can just be put back etc. with no response whatsoever.
I don't think there was any further negotiation that could have elicited a
response.

The NMU was also delayed by 14 days in order to give the maintainer time to
respond. Which they did. Within 3 hours, to simply say "please cancel [this
NMU]."

Don't get me wrong: I use systemd and have no interest in going back to
sysvinit, but to say the sysvinit users didn't try hard enough to negotiate
here seems rather unfair.

------
fimbulvetr
I don't understand why it _needs_ to be so political. IMO, yes, he shouldn't
remove it but there are reasonable alternatives such as another maintainer
setting up a network-manager-sysvinit package that just includes the script
(like git-daemon-sysvinit) or even an entirely new package such as network-
manager-sysv containing the same files and the script. Then everyone can be
happy - the said maintainer can live on without sysv and those that want sysv
can live on with their specialized package.

~~~
raverbashing
Corollary: The most advanced forms of democracy have the most tendency of
descending to something akin to a playground bickering

I think the GR is pretty clear but that doesn't seem to be the 1st time that
Debian maintainers act like they own the ball and are going home with it.

------
phone8675309
I can understand the maintainer saying that they need people to test it
because they run systemd and therefore don't have a system running another
init system to test on. I can't understand removing working support.

Maybe split the SysV support into another package that is maintained by
someone who is able and willing to spend the time testing it under other init
systems.

~~~
pabs3
It is fairly trivial to test other init systems using virtual machines,
booting off another installation on USB or even by installing the other init
system and rebooting. Also, delegating the testing to those using sysvinit and
NM would have been just fine too.

~~~
rleigh
When I was maintaining sysvinit and initscripts, and testing changes to these,
as well as initramfs, lvm, and all other associated packages critical to
booting, that's exactly what I did.

Before upload of every single release, it would have been tested on a battery
of virtual machines using various different configurations, plus bare metal
including non-x86 architectures (powerpc at the time). That was sufficient to
catch the vast majority of regressions upon common and not-so-common setups.
When a single mistake could effectively brick thousands of installations, you
do have a responsibility and duty of care to not ever break system boot.

------
jjav
It is sad Debian has devolved to this. Twenty years ago Debian was the guiding
light in Linux distros, with principled technical leadership in the space. It
is incredible how much damage systemd has caused on the Linux ecosystem.

------
dijit
FWIW Network-manager depends on dbus, and dbus hard depends on systemd for
some years now.

~~~
pabs3
> dbus hard depends on systemd

That doesn't seem to be the case, the dbus package only depends on libsystemd0
and installing dbus in a clean chroot doesn't pull in systemd.

    
    
        $ apt-cache show dbus | grep Depends | grep -o ...systemd. | sort -u
        libsystemd0

~~~
tremon
just FYI, aptitude can identify the dependency chain between two packages. I
don't know if it always finds the shortest chain, the most direct chain
(choosing Depends over Recommends over Suggests), or just any chain, but on
this machine (Ubuntu Xenial, the only one I can access right now):

    
    
      $ aptitude why network-manager systemd
      p   network-manager Depends libpam-systemd
      i   libpam-systemd  Depends systemd (= 229-4ubuntu21.29)
    
      $ aptitude why dbus systemd
      i   dbus            Depends    adduser
      i   adduser         Depends    debconf | debconf-2.0
      i   debconf         Recommends apt-utils (>= 0.5.1)
      i   apt-utils       Depends    apt (= 1.2.32ubuntu0.1)
      i   apt             Depends    gnupg | gnupg2
      i   gnupg2          Depends    gnupg-agent (= 2.1.11-6ubuntu2.1)
      i   gnupg-agent     Depends    pinentry-curses | pinentry
      p   pinentry-gnome3 Provides   pinentry
      p   pinentry-gnome3 Depends    libgtk-3-0 (>= 3.0.0)
      p   libgtk-3-0      Depends    libcolord2 (>= 0.1.10)
      p   libcolord2      Recommends colord
      p   colord          Depends    policykit-1 (>= 0.103)
      i   policykit-1     Depends    libpam-systemd
      i   libpam-systemd  Depends    systemd (= 229-4ubuntu21.29)
    

So yes, network-manager does seem to have a hard dependency on systemd, but
dbus doesn't. Though I'm curious why network-manager should hard-depend on
libpam...

~~~
dane-pgp
> I'm curious why network-manager should hard-depend on libpam...

Meanwhile, some people are trying to work out why a printer driver should
require switching init system to systemd.

[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=863974](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=863974)

> Tags: wontfix

------
sgc
Will this be something that downstream maintainers like Ubuntu etc will be
able to keep going easily, or will it basically hobble them as well over the
next few years?

~~~
pabs3
Ubuntu have also switched to systemd so they are unaffected by this issue.

