On Tue, 28 Apr 2026 13:41:14 +0100 Mark Hindley <[email protected]> wrote: > The arch independent files currently in sysvinit-utils, namely > > /usr/lib/init/init-d-script > /usr/lib/init/vars.sh > /usr/lib/lsb/init-functions > /usr/lib/lsb/init-functions.d/00-verbose > /usr/share/man/man5/init-d-script.5.gz > > fit neatly within the Description of init-system-helpers.
It makes sense for init systems that support init scripts to pull these in; it doesn't make sense for other init systems to do so. Having init systems with init script support depend on sysvinit-utils solves 99% of cases. The only cases that aren't covered by that are cases where a package ships an init script or helper script that sources one of these *and* expects to call that script on a system that doesn't have an init-script-based init system installed (or may not have any init at all). For instance, this would apply to a package that ships /etc/init.d/foo *and* has some non-init script (e.g. a cron job) that invokes the init script. To the extent that packages do that (which they shouldn't), it seems reasonable to say "if your package does that, you need an explicit dependency on sysvinit-utils yourself, because it might be invoked on a system without an init system". That would have the ideal outcome: - Systems containing only packages that *don't* invoke such scripts outside the context of an init system will not need these files. - Systems containing packages that *do* invoke such scripts outside the context of an init system will pull in these files. - Most importantly, nothing Essential or transitively essential pulls in these files, which also means we won't get *new* undocumented dependencies on them.
