On Sat, 21 Nov 2020 at 10:47:17 +0200, Wouter Verhelst wrote: > On Thu, Nov 19, 2020 at 09:04:07AM +0000, Matthew Vernon wrote: > > 1) poor user experience - a package of initscripts would clutter > > /etc/init.d/ with a huge number of files (most of which would be no use to > > the user) > > This could be fairly easily fixed. > > Option one: > - Don't install the init scripts in /etc/init.d, but install them in > /usr/share somewhere. > - Install a dpkg trigger that uses ucf to copy the relevant init scripts > /etc/init.d (and goes through the rest of the dance to enable them) > when the relevant package(s) is/are installed.
Or someone could teach sysv-rc or insserv to look for init scripts in /usr/share/init.d, with an init script in /etc/init.d of the same name taking precedence; or the init script in /etc/init.d could be a symlink to one in /usr/share by default, with the sysadmin able to replace it with a regular file if they want to modify it; or something along those lines. I'm sure people who prefer to use LSB init scripts can work something out. It occurs to me that something along these lines would largely solve one of the ongoing design issues with LSB init scripts (and cron jobs, and other interfaces based on dropping an arbitrary executable script into a designated place in /etc): the fact that they are conffiles, and therefore remain in /etc when their package is removed but not purged. This can break other related or unrelated packages if the script is not correctly guarded by "if [ -x /usr/sbin/something-relevant ]", and is difficult to fix reliably with a package update: script maintainers can of course fix their script to have that guard at any time, but users affected by the bug will not receive the fixed script, because the script's package is no longer installed and so will never be upgraded to a fixed version. I think I've seen several occasions on which an obsolete init script (or cron job or hook or other integration script) remaining on the system triggered RC bugs during upgrade, leading to some related package having to have (non-Policy-compliant!) glue code to remove or otherwise defang the integration script so that the upgrade could proceed. Having that guard also means the script still has to be executed in order to figure out that it doesn't need to do anything, which is a shell invocation that didn't need to happen. Now, this is clearly not the way LSB init scripts have traditionally worked in Debian. However, I note that the winning option in GR 2019-002 says we will "support exploring alternatives". It does not say that we will preserve sysvinit, LSB init scripts and sysv-rc in precisely the way they have traditionally worked in Debian - after a couple of decades I would hope that we have already adequately explored sysv-rc, and have a reasonably clear picture of its advantages and disadvantages. If people want to continue to use it, addressing or mitigating the disadvantages seems like part of the task of maintaining it and keeping it fit-for-purpose. > This puts the burden of maintaining said init script on the maintainer. > In my reading of the GR, that's not expected of maintainers anymore. > > I think it's fair for a maintainer to be expected to file a bug on an > "init scripts" package if their CLI changes. The rest should then be the > job of the maintainers of that init scripts package. That's my understanding too, and Wouter's mail continues by making good points about this topic. If we are unable to use particular system services (in this case NM) with a particular non-default init system without putting extra responsibility on the maintainers of those system services, then I think that's a limitation of that init system that its maintainers could usefully address, and addressing that limitation would certainly be within the scope of exploring alternatives to systemd. smcv