"Systemd but we support exploring alternatives" was what was said in the GR (Choice B in 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".
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.
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.
> 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.
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.
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.
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.
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".