A package for orphaned sysvinit scripts

[The Wanderer]

On 2021-01-02 at 10:11, Matthew Vernon wrote:

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

One thought I'd had, in reading the TC bug discussion, was of the idea
of having more-or-less a package per such init script. The init-script
package could then depend on the package which would otherwise contain
that init script. All of these binary packages could be generated from a
single source package.

(Splitting out the .service files, etc., similarly into different
packages, and then having the central package Depend on the various "tie
this in to be managed by the init system" packages with the one for the
default init system first, would probably be better - but would also
require buy-in from the package maintainers, and probably from the rest
of the project, so is not as likely to be doable.)

As far as I can see the biggest downside to this is the increase in the
number of tiny packages it would produce, with the corresponding
pushback that would generate.

It also wouldn't do anything to ensure that the init scripts are present
when the package which might want them is, so the sysadmin would need to
install each init-script package in a relatively manual fashion - but
then I don't see any way to ensure that without cooperation from the
maintainers of those other packages in any case, so the sysadmin would
need to manually install a hypothetical orphaned-init-scripts package
anyway, this just splits it up more.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20210102/feaceb07/attachment.sig>