Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Am 07.11.2023 um 19:50 schrieb Thorsten Glaser : >> Small but important. A system without (a running) logging daemon is not > > Hmh, but… > “From bookworm, rsyslog is no longer installed by default.” I'm solely talking about system upgrades. Which — at last in my world — happen much more frequently than new installs. >> Should I open up another bug report for making o-s-s a hard dependency for >> (one of) the SysVinit packages? > > 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. OK, thanks for clarifying. :wq! PoC
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
(getting OT…) On Tue, 7 Nov 2023, Ottavio Caruso wrote: >Am Mo., 6. Nov. 2023 um 21:09 Uhr schrieb Axel Beckert : >> 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. Yeah, I wish. >You must be stuck at 2004. Debian has been Canonical's changing room since >then. 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 ☹ >A: Because it messes up the order in which people normally read text. >Q: Why is top-posting such a bad thing? >A: Top-posting. >Q: What is the most annoying thing in e-mail? So indeed! bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (429 (458) bugs: 0 RC, 295 (315) I, 134 (143) M, 0 F) + 210 ‣ src:dash (87 (101) bugs: 0 RC, 48 (51) I, 39 (50) M, 0 F) + 62 ubu ‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F) dash has two RC bugs they just closed because they don’t care about quality…
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
On Tue, 7 Nov 2023, Patrik Schindler wrote: >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. Yes… but, again, that was a rather new thing back then. >> 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. > >Small but important. A system without (a running) logging daemon is not 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. >Should I open up another bug report for making o-s-s a hard dependency >for (one of) the SysVinit packages? 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 -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Am 07.11.2023 um 10:58 schrieb Matthew Vernon : > do feel free to propose some text for them). How would be the proper way to do so? > 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. Thank you. For the time being, I'm reluctant to go through the same chore again anytime soon. > [are we at the point where this bug report can be closed? From my side: Yes. 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
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Hi, On 07/11/2023 01:14, Patrik Schindler wrote: Am 07.11.2023 um 01:59 schrieb Thorsten Glaser : I have sysvinit-core installed and orphan-sysvinit-scripts was not pulled in automatically. Yeah, it’s not. 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. Yes, it's a Recommends: which means it'll be pulled in on most upgrades (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
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Am Mo., 6. Nov. 2023 um 21:09 Uhr schrieb Axel Beckert : > > 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. You must be stuck at 2004. Debian has been Canonical's changing room since then. -- Ottavio Caruso A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Am 07.11.2023 um 02:28 schrieb Thorsten Glaser : >> 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. > > 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). 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. > 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. 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. > 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. 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? >>> I dislike the having the init scripts separate very much, too. But it’s >>> either that… >> >> … or try to reconcile Devuan efforts with Debian policies. > > Ugh, no. 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
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
On Tue, 7 Nov 2023, Patrik Schindler wrote: >>> I have sysvinit-core installed and orphan-sysvinit-scripts was not pulled >>> in automatically. >> Yeah, it’s not. > >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. 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. >> I dislike the having the init scripts separate very much, too. But it’s >> either that… > >… or try to reconcile Devuan efforts with Debian policies. Ugh, no. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Am 07.11.2023 um 01:59 schrieb Thorsten Glaser : >> I have sysvinit-core installed and orphan-sysvinit-scripts was not pulled in >> automatically. > Yeah, it’s not. 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. > I dislike the having the init scripts separate very much, too. But it’s > either that… … or try to reconcile Devuan efforts with Debian policies. :wq! PoC
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
On Tue, 7 Nov 2023, Patrik Schindler wrote: >I have sysvinit-core installed and orphan-sysvinit-scripts was not >pulled in automatically. Yeah, it’s not. The release notes should have mentioned this, but for some reason, no text made it there. >For Debian 11, there was no need for this package (for me!) and it's 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 ☹ >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. 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 -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Am 06.11.2023 um 21:20 schrieb Matthias Geiger : > This is caused by package maintainers just dropping init scripts, and not > honoring the GR about init systems in Debian. May I ask you to elaborate? What is GR? > 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. I have sysvinit-core installed and orphan-sysvinit-scripts was not pulled in automatically. 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. > While some people would be probably happy to see sysvinit go it'd be a big > loss for debian at whole. I don't *want* it to go. In fact, I want to have it. But in a proper state. 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
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Hi, Patrik Schindler wrote: > 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. Works fine for me, especially in Bookworm. Running servers as well as workstations with it. > For this reason, I propose to remove SysVinit completely from the next Debian > release, 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 -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
On 06.11.23 21:09, Thorsten Glaser wrote: On Mon, 6 Nov 2023, Patrik Schindler wrote: For this reason, I propose to remove SysVinit completely from the next Debian 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, -- Matthias Geiger Debian Maintainer "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
On Mon, 6 Nov 2023, Patrik Schindler wrote: >For this reason, I propose to remove SysVinit completely from the next Debian Uhm NO‽ *shaking head*, //mirabilos
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Package: sysvinit-core Version: 3.06-4 Severity: wishlist 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. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages sysvinit-core depends on: ii debconf [debconf-2.0] 1.5.82 ii initscripts3.06-4 ii libc6 2.36-9+deb12u3 ii libselinux13.4-1+b6 ii mount 2.38.1-5+b1 ii sysv-rc3.06-4 ii sysvinit-utils 3.06-4 Versions of packages sysvinit-core recommends: pn orphan-sysvinit-scripts Versions of packages sysvinit-core suggests: ii bootlogd 3.06-4 -- debconf information excluded
