Bug#1131136: sysvinit-utils does not need to be in Essential set

[Andrew Bower]

On Sat, Apr 18, 2026 at 09:45:43AM +0200, Andreas Henriksson wrote:
> Thanks for providing feedback on this topic! Even though I promised
> myself to stay out of this discussion, I can't help but add my 5c...
> Hopefully you find something informational, helpful and/or maybe
> interesting from a historical perspective, otherwise please feel free to
> ignore.
> 
> On Fri, Apr 17, 2026 at 04:48:44PM +0100, Mark Hindley wrote:
> > Gioele,
> > 
> > Thanks for this and your patience in waiting for a reply.
> > 
> > On Thu, Apr 16, 2026 at 12:02:26PM +0200, Gioele Barabucci wrote:
> > > Hi, any feedback on this plan?
> > 
> > There have been some discussions and there is uncertainty that your proposed
> > migration covers all the necessary angles.
> > 
> > Quoting from your original email:
> > 
> > > The Essential bit can be removed because, after years of work, no 
> > > package make use of `pidof` in their maintscripts. (Except 5 low-popcon 
> > > packages for which patches and bug reports has already been submitted.)
> > 
> > This doesn't cover runtime users of pidof or init-d-script.

(And not just init-d-script which benefits a minority of packages but
init-functions and vars.sh etc. which would affect a large number.)

> In my opinion (and also apparently the opinion of sysvinit maintainers
> in the past, more on this later) is that sysvinit should pull in the
> parts that is the expected execution environment for init scripts
> (instead of duplicating this in every package that ships an init
> script - which I agree is probably better maintained by
> application maintainers themselves if possible).

I do like the idea of avoiding extra friction for individual packages to
be able to hold an initscript. At worst I think we should require
dh_installinit to add to ${misc:Depends}, which would avoid source
packages needing to tbe changed, but much better is if the dependency
does not even need to be expressed in the binary package at all, as I
think you are implying.

My concern is whether we have identified all the use cases
comprehensively and how much it matters for any that would not have this
implied dependency satisfied.

Considering the use cases:

 1) sysv-rc - the obvious one - easy, and already satisfied by a
    versioned Depends, as it happens!

 2) openrc, runit-init, etc., where fallback to initscripts is key to
    being comprehensive - presumably straightforward.

 3) initless containers and similar.

The last one is the interesting one. Are there any use cases for
initscripts being launched in isolation, by invoke-rc.d or similar? I
have seen this happen benefically in autopkgtests (not sure which
backend etc. - the same test used systemd in salsa and debci) for
example. I am not saying this is a big deal, that the use cases are
numerous or that they wouldn't already be satisfied indirectly[1], but I
think this deserves a little examination before proceeding, not least
because it might overlap with whatever the use cases are that are going
to benefit from this slightly reduced Essential set!

Thanks,

Andrew

[1] Or perhaps such use cases are potentially better satisfied by
src:systemctl.