They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.
My take away is that they have a great system which allowed for voices to be heard, perspectives to be presented, and for an ultimate decision made in the best interest of Debian users. Doesn't seem a waste of time to me.
This view can be summarized as "why can't the package maintainers just do the right thing themselves all the time and get along with everybody?" which is just an astonishing question to someone who has actually worked with other humans.
If there wasn't a committee, the change would have been made and a lot of people would have suffered. In this particular case, the time spent in following the process is negligible compared to the damage this change would have caused.
The maintainer wanted to no longer support a part of their package. In almost every single situation this would have a natural result with the maintainer stopping to support the thing they don't want to spend their volunteer time on and any other developer who want to support it could pick it up.
It is actually a bit insane that the committee is forcing a developer to support something against their will in a project based on volunteers. It is basically an artifact of the concept of essential packages and an situation where multiple different versions could cause instability, and so until the program can be moved to a different essential package the best move for the project was to keep things as they were.
I don't get why they can't switch to GNU which and put it in whatever package it harmonizes with. Throwing out deprecation notices for core utilities is irresponsible.
Absolutely. Transparent governance is really hard, and it was quite nice to see an example of a conflict handled and resolved so well, right out in the open.
I have no gripe about the process. (Well, I don't think it was a technical decision, so it shouldn't have been dumped on the TC). It was pellucidly transparent. Exemplary, really.
I just really don't like systemd, so I'm sorry that it became the Debian default init. My gripe is with the outcome, not the process. Most package-maintainers must have disagreed with me. It's OK, I'm used to people not agreeing with me.
What tangible thing does systemd do that hurts your usage of the OS?
If I would hack into your computer, install systemd and set up a few clever aliases for your sysvinit commands, would you ever notice that I have done that?
I see this hard anti-systemd sentiment from some vocal people, but I have yet to see any actual problems that systemd has caused.
I know that systemd is not a POSIX standard, but neither is sysvinit.
> What tangible thing does systemd do that hurts your usage of the OS?
Well, binary logging, for a start. Usurping DNS.
Actually, let's not go down that path - it would be a long argument, and I've already lost it, years ago.
> would you ever notice that I have done that?
Umm, yes.
My case isn't that systemd is bad; it's that I objected to Debian making systemd the default init, and that it's not very easy to make a non-default init the active init. I have a preference, I don't think I have to justify it, but the Debian change made it hard for me to exercise that preference. That's all.
Systemd broke my computers plenty of times; the closed logging system spread the logs into the things systemd managed and what the application manages; there were the DNS problems that Debian solved quickly; and the moronic timeouts, why fail a service in a second when you can keep retrying and increasing the timeout for 15 minutes, dragging the boot sequence and making sure nobody can fix the problem for all that time?
There were many more, but I don't write it down. Systemd is a horrible piece of software that solves a very important problem.
Not Devuan, normal vanilla Debian (and one Debian-Xen VM host).
There are instructions online for removing systemd; I think it is cause for regret that there isn't an install option and a commandline tool to "just do it". It's not tricky; it's just a nuisance that you have to do it at all.
[Edit] And a debconfig thing. It should be that easy to switch.
[Edit 2] I deserve to be voted down, I realise! I called for a change that I claimed was easy, without offering a patch! I should shut up, and my remarks should be very pale grey.
The POSIX shell builtin command -v <name> basically already functions like which, and the whole purpose of which is to tell you where in $PATH a command is
They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.