After I've upgraded my server to Bookworm today, I'll now do a rollback from
backup because of numerous issues with many services not coming up anymore.
All due to the decreasing willingness of maintainers to support SysVinit, by
intentionally removing /etc/init.d scripts from packages.

Debian offering SysVinit packages is at least with Debian 12 just a fig leaf,
luring users into believing they have a choice of init system which they in
fact lack. Increasingly so with every new release of Debian Linux.

This lack of true support renders production machines faulty at upgrade time,
which is an absolute no-go, IMHO!

For this reason, I propose to remove SysVinit completely from the next Debian
release, with appropriate checking routines at upgrade time, so upgraded
machines won't run into a "don't boot anymore" condition. This will make a
clear statement for everybody instead of the current ambiguity where individual
packages arbitrarily support SysVinit or not, at the mercy of their
maintainers.

Uhm NO‽

*shaking head*,
//mirabilos

This is caused by package maintainers just dropping init scripts, and
not honoring the GR about init systems in Debian.

The init-diversity team has been putting a lot of work into maintaining
sysvinit and related packages; please appreciate the effort they are
putting in.

sysvinit (or openRC, in my case) is still usable with debian. The
dropped scripts are provided by the orphan-sysvinit-scripts page.

While some people would be probably happy to see sysvinit go it'd be a
big loss for debian at whole.

best,

Hi,

Patrik Schindler wrote:

Works fine for me, especially in Bookworm. Running servers as well as
workstations with it.

You are trolling us, right? The opposite is the proper implication
from what you've described.

Debian is about choice, not about spoon-feeding users and leaving them
without choice in many places like at least one well-known Debian
derivative does.

		Regards, Axel

Hi,

Patrik Schindler wrote:

Works fine for me, especially in Bookworm. Running servers as well as
workstations with it.

You are trolling us, right? The opposite is the proper implication
from what you've described.

Debian is about choice, not about spoon-feeding users and leaving them
without choice in many places like at least one well-known Debian
derivative does.

		Regards, Axel

Am 06.11.2023 um 21:20 schrieb Matthias Geiger <werdahias@riseup.net>:

May I ask you to elaborate? What is GR?

In fact, I wasn't aware about orphan-sysvinit-scripts until just now. I would have expected something that important to be mentioned in the "issues" documentation: https://www.debian.org/releases/stable/amd64/release-notes/ch-moreinfo.en.html

For Debian 11, there was no need for this package (for me!) and it's also not mentioned in the bullseye documentation: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html

Bottom line: Something about dependencies went wrong in an unexpected way. The first time that it had such grave impact. I'm using Debian since 3.0 and was very happy that system upgrades were rather painless. Until now.

I also don't want to experience following the documentation, upgrade my machines(s), and be faced with an unknown amount of services not coming up, in the end costing me a whole day to wade through conffiles, with questionable changes being unloaded to the sysadmin (the master/slave/whitelist/blacklist discussion) and discovering that half of the system just doesn't come up because of maintainer's neglect of SysVinit.

~ $ dpkg -l |wc -l
1315

Maybe you can understand my frustration. I don't intent to belittle anyones efforts in keeping SysVinit alive on Debian, but the current state of affair is a foul compromise to not confront maintainers: Package-separate initscripts do not sound like a good idea but a workaround for a political issue. When things become political, they become messy. My experience.

:wq! PoC

Yeah, it’s not. The release notes should have mentioned this,
but for some reason, no text made it there.

Me either, asides from nftables things still had init scripts
there. In bookworm, “unimportant” packages like lvm lost their
init scripts, and it’s getting m̲u̲c̲h̲ worse for trixie ☹

Yes, indeed. Personally, I’m sticking to bullseye for the next,
uh six or so years with ELTS. But that’s no reason to give up
the fight for diversity, as long as people are still doing that.
Running testing or unstable with sysvinit is now out for normal
people though.

I dislike the having the init scripts separate very much, too.
But it’s either that…

bye,
//mirabilos

Am 07.11.2023 um 01:59 schrieb Thorsten Glaser <t.glaser@tarent.de>:

As I'm learning from a discussion in bug #1055466, this is due to orphan-sysvinit-scripts "only" being recommended and not a hard dependency.

… or try to reconcile Devuan efforts with Debian policies.

:wq! PoC

Recommends count, they are installed by default since, uh, lenny
or so (a decision I still personally revert on all systems because
that also includes transitive Recommends; instead I inspect the
list of recommended packages manually).

In trixie, o-s-s definitely should be a Depends of one of the
packages (sysvinit? sysv-rc? or what?) but it was too late for
bookworm, and it only affected users of a small number of packages
there, IIRC.

But yes, maybe that should be fixed in a stable upgrade, now that
we know o-s-s is here to stay, it will be required in the next
release, and there is visible user impact. Back then these things
weren’t yet this clear.

Ugh, no.

bye,
//mirabilos

Am 07.11.2023 um 02:28 schrieb Thorsten Glaser <t.glaser@tarent.de>:

Reiterating what I've stated in #1055466 in other words… leaving aside recommends-are-default, missing recommends IMHO should not half-break a system at upgrade time.

Small but important. A system without (a running) logging daemon is not a proper Linux system. What exactly should pull in is probably a mere matter of taste.

Well, I definitely got some bruises and I'm still contemplating about other distro options.

Should I open up another bug report for making o-s-s a hard dependency for (one of) the SysVinit packages?

Sigh. That's why I hate politics. Technology can't fix what politics and half-cooked compromises has broken. And affected users stay behind with "WTF".

:wq! PoC

Am Mo., 6. Nov. 2023 um 21:09 Uhr schrieb Axel Beckert <abe@debian.org>:

You must be stuck at 2004. Debian has been Canonical's changing room since then.

Am Mo., 6. Nov. 2023 um 21:09 Uhr schrieb Axel Beckert <abe@debian.org>:

You must be stuck at 2004. Debian has been Canonical's changing room since then.

Hi,
(I agree it would have been better to have got something into the
release notes; I don't know if they are still taking updates for the
bookworm release notes, but do feel free to propose some text for them).

If you find future init scripts missing that aren't in
orphan-sysvinit-scripts and the relevant package maintainer isn't
willing to restore them, do file a bug report (ideally with the
requested details from the README -
https://salsa.debian.org/matthew/orphan-sysvinit-scripts/ ) against
o-s-s and we can get them into trixie.

I had thought we'd caught nearly all of the scripts from bookworm, but
if there are missing ones there we could try and get a fix into the next
point release.

[are we at the point where this bug report can be closed? I feel like
there might be a bug report with patch if you want the release notes
updating, and/or bugs for particular missing init scripts]

Regards,

Matthew

Am 07.11.2023 um 10:58 schrieb Matthew Vernon <matthew@debian.org>:

How would be the proper way to do so?

Thank you.

For the time being, I'm reluctant to go through the same chore again anytime soon.

Q: Should I open up a proper bug report to make o-s-s not a recommended but a hard dependency package? Or is this discussion enough that this will be triggered by the SysVinit maintainers?

:wq! PoC

Yes… but, again, that was a rather new thing back then.

Hmh, but…
“From bookworm, rsyslog is no longer installed by default.”
… is in the release notes at least, and the init script thing
is annoying, yeah… but inetutils-syslogd works.

Hm, I don’t know if that would be helpful at the moment. And
if SRM need one we could just repurpose/retitle this one, as
that would be the better outcome.

Mark, do you already have a plan for this? Talk to SRM and see
whether we can get that Depends into the next point release at
least? Is o-s-s stable enough in bookworm to do that?

bye,
//mirabilos

(getting OT…)

Yeah, I wish.

The mksh package is STILL suffering from Canonical’s dash package
and its maintainers and the release managers ignoring RC bugs in
that that prevent mksh from sanely taking over /bin/sh for way
too long ☹

So indeed!

bye,
//mirabilos

Am 07.11.2023 um 19:50 schrieb Thorsten Glaser <t.glaser@tarent.de>:

I'm solely talking about system upgrades. Which — at last in my world — happen much more frequently than new installs.

OK, thanks for clarifying.

:wq! PoC

My debian testing installation cannot boot from systemd.
I can only use sysvinit under Debian. This seems to be
a complete betrayal of the whole linux philosopy.

I forget just now why systemd cannot handle that particular box.
I will presumably be forced to dump Debian, and probably go to Devuan
if this ridiculous proposal goes through.

ael