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

[Andreas Henriksson]

Hello Mark,

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.

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 have been reading the Policy in the hope of finding an escape from the bind we
> are in. Policy says:-
> 
>   Packages are not required to declare any dependencies they have on other
>   packages which are marked Essential (see below), and should not do so unless
>   they depend on a particular version of that package. [4]
> 
> and [4] adds
> 
>   Essential is needed in part to avoid unresolvable dependency loops on
>   upgrade. If packages add unnecessary dependencies on packages in this set, the
>   chances that there will be an unresolvable dependency loop caused by forcing
>   these Essential packages to be configured first before they need to be is
>   greatly increased. It also increases the chances that frontends will be unable
>   to calculate an upgrade path, even if one exists.
> 
>   Also, functionality is rarely ever removed from the Essential set, but
>   packages have been removed from the Essential set when the functionality moved
>   to a different package. So depending on these packages just in case they stop
>   being essential does way more harm than good.
> 
> So, currently no callers of pidof or init-d-script should declare an unversioned
> Depends: sysvinit-utils.
> 
> But, by removing the Essential bit, all users of pidof or init-d-script (not
> just maintscript users) will immediately become RC buggy by failing to comply
> with the Policy requirement that

> 
>   Every package must specify the dependency information about other packages
>   that are required for the first to work correctly.
> 
> So which of these Policy directives do we break?

The solution is that src:sysvinit in the same version that drops the
essential bit from sysvinit-utils, also adds a dependency on the package
that provides pidof implementation. No policy violation, no bugs
introduced.

This actually used to be the situation in the past, that sysvinit
depended on sysvinit-utils.... so this was not a problem until
someone decided to make this a problem by fixing the policy violation
by dropping the dependency instead of dropping the essential bit as
requested. Feel free to do your own bug tracker and git[1] history
archeology if you want more details.

> 
> The consensus from the discussions we have had so far is that it would be best
> to add Depends: sysvinit-utils where required *before* removing its Essential
> bit to avoid any time where the necessary dependencies are not declared.
> 
> There is also an issue that the commandline options of procps' pidof are not
> identical. Are you sure there are no runtime users of pidof that rely on the
> current semantics?

Any such code is already non-portable to any other distribution (which
uses the procps implementation of pidof), so I would consider that a bug
unless it's in debian-specific code (i.e. maint scripts, which have all
been investigated).

> 
> Do you see a better way through?

Yes, the solution is that sysvinit re-adds the sysvinit-utils dependency, as
already mentioned as already mentioned above.


I would also like to add that any init script that directly invokes
pidof is likely buggy and should instead use LSB pidofproc (or even some
more high level function, possibly even a policy-mandated helper).
Probably a good idea to expose those bugs and get them fixed at some
point (or how long should we keep working around buggy init scripts
instead of fixing them?).

Another point here is that the work Gioele mentioned has happened to get
rid of pidof usage has been almost exclusively been "replace pidof usage
with policy mandated helpers". Policy is not supposed to be something to
hide behind, but something to help guide us. When policy is buggy or
problematic, we fix policy (which is still in need of alot of love as
always). We could have proceeded by just filing RC bugs and gotten rid
of all blockers from the archive, but we proceeded to fix bugs instead.
I'm hoping we can work to fix bugs and make progress instead of discuss
what our personal preferred interpretation of policy is.

FWIW policy also used to document implementation details about sysvinit
that would make the entire existance of startpar and insserv be RC bugs
until yours truely got those parts removed from policy (because fixing
policy was the correct way forward instead of arguing about policy
violations even though fixing policy in this single case was a
multi-year effort to get the changes actually merged... unchanged).

Over the past few releases a number of people have been involved with
getting rid of essential bit from several packages and also getting
priority downgraded on even more packages, to avoid them being part
of the minimal debootstrap set. This work has been hugely sucessful
with minimal impact to the overall usage of debian. If we can't make
progress on low-hanging fruit like sysvinit-utils until all init scripts
has been removed from the archive, then so be it...

> 
> With best wishes
> 
> Mark

Regards,
Andreas Henriksson


[1]: 8ce88afb25862849f402a1d46cf081aa65ac7438