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