Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
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
Reply to: