A package for orphaned sysvinit scripts
Martin Steigerwald
martin at lichtvoll.de
Sat Jan 2 18:40:43 GMT 2021
Matthew Vernon - 02.01.21, 16:11:40 CET:
> I think the least-bad answer is something like:
Ok, I try to at least give a somewhat constructive answer to this,
instead of just mentioning that I consider Debian => Devuan and be done
with it.
> A package orphaned-sysvinit-scripts that has a directory
> /usr/share/orphaned-sysvinit-scripts/ that contains files that are
> managed with ucf / dh_ucf to have /etc/init.d/thing as config files
>
> e.g. machinery that will run
>
> ucf /usr/share/orphaned-sysvinit-scripts/network-manager
> /etc/init.d/network-manager
>
> The downside of this is that /etc/init.d/ fills up with unnecessary
> init-scripts - a problem will get worse as we have more orphaned
> scripts.
I think this would probably be the easiest one to implement.
> An alternative would be to use dpkg triggers to only create the
> /etc/init.d/ links for files where the relevant package is installed,
> but that would require co-operation from maintainers of packages that
> are ditching their init scripts (which, let's face it, seems unlikely
> to be forthcoming).
Unlikely, yes.
> A third (and hardest work) approach would be to have the config-files
> be under, say, /etc/orphaned-sysvinit-scripts/ and then provide a
> script that re-scans the list of installed packages and
> creates/removes symlinks into /etc/init.d as required. The problem
> here is that there's no mechanism to arrange for this script to be
> run automatically (and there isn't AFAICS a dpkg trigger for "run
> this whenever a package is installed" or equivalent), so you'd have
> to arrange to run it on system boot or somesuch, which might well be
> too invasive (and would mean it would have to be fast and
> reliable)...?
>
> I'd be interested in other perspectives on these approaches, mindful
> that we're not over-endowed with time...
I think I'd prefer something along what Simon wrote in the tech-ctte
bug:
> 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.
Re: Bug#975075: tech-ctte: Should maintainers be able to block init
compatibility changes?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#114
But I believe this would be the most work and it would best involve an
improvement to the upstream software.
So I see this as out of scope for Bullseye.
Best,
--
Martin
More information about the Debian-init-diversity
mailing list