Bug#1131136: sysvinit-utils does not need to be in Essential set
Gioele Barabucci
gioele at svario.it
Thu Apr 23 01:04:08 BST 2026
On 21/04/26 11:16, Mark Hindley wrote:
> I think we might have a confusion in terminology. I apologise in advance if I am
> already stating something you know.
Hi Mark,
thanks for the clarification. I was indeed not thinking of
init-d-script(5). Now I have integrated it in my analysis.
> By init-d-script I believe Andrew and I mean the init-d-script(5) library
> installed at /usr/lib/init/init-d-script by sysvinit-utils that allows
> declarative LSB initscripts. Any package that uses init-d-script(5) requires
> sysvinit-utils be installed, as identified by Michael in #826215.
>
> It seems as if packages using init-d-script(5) need to gain a dependency on
> sysvinit-utils before the Essential bit is removed.
Once again I think we need to distinguish between different scenarios:
1. Custom installations (like init-less container images). As Luca said,
custom setups always have to do additional steps in order to get the
level of customization they like. Adding sysvinit-tools will be just one
of other similar steps (and will be documented in NEWS).
2. Initscripts run on systems where init=sysvinit. These initscripts
will find pidof and init-d-script where they expect it because
sysvinit-utils is pulled in by sysvinit-core. No extra dependencies needed.
3. Initscripts run on systems where init=systemd. These initscripts will
run only if called at runtime by programs (or systemd service units)
shipped by a package. Do these packages exist? Yes, I extended my
semi-manual analysis to extra 1200 candidate packages and, in fact,
there is a couple of packages that ship programs that call initscripts
at runtime. In the future (not soon once Essential=yes will be gone, but
only once Priority will be set to optional), these packages will fail at
runtime because of the lack of init-d-script. At that point they will
need to hard-depend on sysvinit-utils.
To fix 3, maybe I could start a small MBF for "this package needs
sysvinit-utils as Depends: because it uses files from it (except pidof)
at runtime/test-time" before removing Essential:yes from sysvinit-utils?
But back to the initial intent of the bug report: is there consensus,
that, with these minor issues fixed:
a) the Essential bit can be removed, and
b) pidof can be removed from sysvinit-utils and procps can start
shipping it (once the pidof-related MBF is mostly completed)?
?
Regards,
--
Gioele Barabucci
More information about the Debian-init-diversity
mailing list