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".
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".
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.
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.
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.
I haven't followed Debian in recent years, but I thought the technical committee had said that maintainers were not to remove working sysvinit support nor refuse patches for it, unless the package itself was clearly tied to the specific init system?
> For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason.
Personally I find the /etc/init.d scripts to be crufty & in the way, & would rather not have them in my system.
But I acknowledge there being other folks who for whatever reason prefer SysV style. And the maintainer's silent treatment is pretty harsh.
I would like to give these other users a path forward, but at the same time, I don't want this file in /etc/init.d/ . It's in the way of a better functioning systemd system, I believe; not an area i'm well versed in but I think the init-script helpers expect only an /etc/init.d/ or /etc/systemd/system file, not both, and the /etc/init.d/ script is much less powerful & usable.
Init scripts in /etc/init.d/ are not used when there is a systemd unit of the same name. Other than being in your filesystem they have zero effect on you.
> The most recent Debian General Resolution on init support said something like "we chose systemd but compatibility with other inits is important"
It actually said "Systemd but we support exploring alternatives".
I read this very differently. I read this as Systemd is supported, and if package maintainers wish to include other options they may, with a view to exploring future alternatives.
I don't read this as requiring or prioritising support for previous systems that Debian has moved away from.
What's sad is this is the kind of thing that makes Debian unstable in my eyes. Being able to choose whatever init system you want on your Linux distro is something that should just be a thing.
Additionally I'm confused are these packages not pulled from another source or is Debian the sole developer of this one? I would expect support for other init systems to be in parity with the parent project of the package in question as a result of basing your work off of theirs.
My only experience with Debian packaging is at work and not involved with actual Debian maintainers so I'm unsure of their own process. Is there someone who can shed some light on this?
The init script is specific to Debian. I don't know what network-manager's stance is on init system support or even if they have one. I wasn't able to find one in a quick search.
Oh that's right, it does ask when you upgrade which script you'd like to use.... The package maintainers, yours and possibly the original one(?)... I can't for the life of me remember the options, but I know it usually asks which one you want between yours and the 'package maintainers version' every time you upgrade.
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.
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.
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.
Totally agree with this viewpoint and why I too have left Debian and all related variants. While Devuan and MX Linux try to use other inint systems, their path will be much harder in the future.
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.
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.
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.
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.
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.
On the other hand, the maintainer ignored the discussion until the NMU was submitted, so it at least had this merit (although, still not useful, since the maintainer is still discarding the issue and refusing to explain his choices).
Lets get some perspective here. This change actively and intentionally broke working systems. Let that sink in before considering the severity of the problem and the appropriateness of the actions.
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.
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.
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.
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.
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.
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...
It's an optional dependency, which you activate at compilation time with `./configure --enable-systemd`. So on systems where users don't control build flags, D-Bus dependency on systemd is a decision made by maintainer.
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?
The Debian systemd maintainers did get a lot of abuse during the sysvinit to systemd transition, so that would definitely not be surprising if he were burnt out.
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".