A package for orphaned sysvinit scripts

[Matthew Vernon]

Hi,

While the TC has not yet ruled on #975075, my reading of the tea leaves 
is that they are not going to overrule the maintainer on removing the 
network-manager sysvinit script.

Does anyone have an idea of which packages are affected? I imagine it's 
more than just network-manager?

This means we need some way to provide these for our users. I hope that 
it will remain a minority of packages, and that most people will 
continue to keep their init scripts where they belong (IMO :) ).

The freeze is coming, so we need _something_ quite soon since it'll have 
to get through the ftpmaster NEW queue.

I think the least-bad answer is something like:

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.

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).

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...

Regards,

Matthew