A package for orphaned sysvinit scripts

[Martin Steigerwald]

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