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