A package for orphaned sysvinit scripts
Matthew Vernon
matthew at debian.org
Sat Jan 2 15:11:40 GMT 2021
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
More information about the Debian-init-diversity
mailing list