Debian Policy Updated Following Recent Systemd "Init System Diversity" Vote

[starshipeleven]

Well anyway this decision should be good for both groups.

how can it be good for both groups if they have completely opposite views?
Asking for a friend

FYI: the decision is basically "keep the status quo" which is a victory for the haters

[starshipeleven]

If systemd is for starting and stopping services, why a lot of programs need libsystemd0 (such as Xorg)?

because it is not just for starting and stopping services duh

[Karl Napf]

FYI: the decision is basically "keep the status quo" which is a victory for the haters

Debian just changed its policy to not require a sysv-init script anymore as a direct result of that decision. They are pushing towards allowing systemd-sysusers, systemd-tmpfiles.d and more to be acceptable.

Finally Debian is actually getting some benefit from their move to systemd! So far they just took in all the pain of switching, but stopped using anything that makes systemd nice to have.

[Delgarde]

Debian just changed its policy to not require a sysv-init script anymore as a direct result of that decision.

So basically, it's an acknowledgement that half the package-maintainers were complaining about the previous policy, and the other half were outright ignoring it and not bothering with sysv scripts at all?

[royce]

Sysv scripts are an absolute nightmare to get right and require tons of boilerplate to make them work.

[starshipeleven]

Debian just changed its policy to not require a sysv-init script anymore as a direct result of that decision.

And this changes the current situation in what way?

The status quo is a mixture of "we don't give a shit about initscripts" (so the script is either missing or garbage) and "why write a proper systemd unit when you can just write a shim calling a script doing all the work" (so the systemd unit is garbage) depending on the maintainer's view.

An actual change would have been to drop support for one init and force EVERYONE to use the TRUE AND ONLY init by either writing proper init scripts or proper systemd service units.

[Karl Napf]

The status quo is a mixture of "we don't give a shit about initscripts" (so the script is either missing or garbage) and "why write a proper systemd unit when you can just write a shim calling a script doing all the work" (so the systemd unit is garbage) depending on the maintainer's view.

The policy change pushes the project more towards "we don't give a shit about initscripts" and the decision causing that update also opens the door for more systemd features which were totally out of scope for Debian so far.

I am convinced that this does change the status quo. On the other hand: We are talking about Debian, so any change will take a while to bear fruit.

An actual change would have been to drop support for one init and force EVERYONE to use the TRUE AND ONLY init by either writing proper init scripts or proper systemd service units.

Such a decision is unthinkable for Debian -- in fact for pretty much any volunteer-driven organization.

But Debian's decision is as close to that as possible in a project as big and diverse as Debian. It will now take a couple of month to turn that decision into policies.

[starshipeleven]

The policy change pushes the project more towards "we don't give a shit about initscripts"

Not really. They didn't choose a default init so the usual suspects will still play the "but we must support multiple inits" card, while those that didn't care still don't care

Such a decision is unthinkable for Debian -- in fact for pretty much any volunteer-driven organization.

For debian, yeah, they must be inclusive of trolls and morons too for some reason, for most volunteer-driven organizations... are you kidding me?

Is OpenWrt supporing multiple inits? Is Void Linux supporting multiple inits? Is *BSD supporting multiple inits? What about Arch?

And if you ask for that in their mailing lists citing the bs reasons that actually fly on Debian they'll laugh at you.

[Karl Napf]

Not really. They didn't choose a default init so the usual suspects will still play the "but we must support multiple inits" card, while those that didn't care still don't care

But they did de-facto: Packages must ship systemd units now. Systemd must work and breakage there can stop a release.

If somebody wants anything else to work, then that somebody needs to put in the work and maintainers may or may not accept the required changes as they see fit. You can't stop somebody from doing that work if they want, so there is no harm in allowing this explicitly:-)

Is OpenWrt supporing multiple inits? Is Void Linux supporting multiple inits? Is *BSD supporting multiple inits? What about Arch?

Does Debian support multiple inits? You get one init pre-installed out of the box and that is the supported one. Anything else requires you to put in extra work.

I see little difference between the Linux distributions you listed and Debian -- if you put aside the talk and just look at the packages.

The whole idea of "init freedom" in a distribution is bullshit ever since the term was coined by a bunch of morons that can't produce a distribution by themselves.

[ZeroPointEnergy]

I still try to figure out which party has the bigger morons, the systemd "hater" with their ridiculous a gazillion times debunked arguments about systemd being a monolith or the systemd fanboys with their ridiculous "everyone not in our team is an enemy" tribalism.