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

[Gioele Barabucci]

On 17/04/26 17:48, Mark Hindley wrote:
> 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.

Hi, thanks for taking the time to evaluate my proposal and draft such a 
detailed response!

Before addressing your comments I would like to remind you that removing 
Essential:yes is only the first step of the process. I'll focus on it in 
this reply, but the whole process described in my original email is what 
should be agreed upon.

> 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.

Right. But keep in mind that these are two different use cases, to be 
discussed and treated differently.

> So, currently no callers of pidof or init-d-script should declare an unversioned
> Depends: sysvinit-utils.

Right.

> 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.

Not exactly. Not if I've done my homework correctly. Maybe I'm 
overlooking something. Please poke holes in my reasoning.

There are three categories of pidof-using packages:

pidof0. use pidof in their maintscripts;
pidof1. use pidof in their init.d scripts;
pidof2. use pidof at runtime.

(Obviously some packages belong to more than one category.)

Category pidof0 is now empty (OK, there are at the moment 4 low-popcon 
packages left. They will be NMUed before Essential is removed), so we 
ignore it for the rest of this discussion.

Then there are two init systems:

init1. sysvinit
init2. systemd

(For the sake of the following analysis, all other init systems can be 
grouped into init1 with minor or no changes.)

So in total we have to understand what happens in four scenarios:

A = pidof1 + init1
B = pidof1 + init2
C = pidof2 + init1
D = pidof2 + init2

# Scenario A (pidof in init.d-script, sysvinit)

All sysvinit systems have sysvinit-core, which ships /sbin/init. 
sysvinit-core hard-depends on sysvinit-utils (currently for min-version 
reasons, but that constraint can be removed and the dependency left in 
place).

This means that whenever an init.d-script will actually be run, it will 
surely find sysvinit-utils  in place (and thus also pidof).

Removing the Essential bit will have no effect in this scenario.

# Scenario B (pidof in init.d-script, systemd)

sysvinit-utils may or may not be installed, but no init.d script will 
actually be run at runtime. (I checked: none of the pidof-using 
init.d-scripts are used inside systemd service units in Exec*= lines. I 
checked manually, so there may be mistakes, but we are talking about a 
handful of packages at worst.)

Removing the Essential bit will have no effect in this scenario.

# Scenario C (pidof at runtime, sysvinit)

Like scenario A: sysvinit users always have sysvinit-utils installed, so 
the programs will always have pidof available at runtime.

Removing the Essential bit will have no effect in this scenario.

# Scenario D (pidof at runtime, systemd)

This is the one scenario that needs careful handling.

Theoretically and strictly speaking, without an explicit dependency on 
sysvinit-utils, packages that use pidof at runtime will break in some 
way. And be RC-buggy because of a missing dependency. This is why a MBF 
is needed.

However, a future sysvinit-utils without Essential: yes will still have 
Priority: required. This means that, in practice, debian-installer 
(through debootstrap) will still install sysvinit-utils an all systems 
because of its Priority, even if it is not Essential. It will also be 
kept during updates.

What about removals? Policy states:

> Packages which are necessary for the proper functioning of the system
> (usually, this means that dpkg functionality depends on these
> packages). Removing a required package may cause your system to
> become totally broken and you may not even be able to use dpkg to put
> things back, so only do so if you know what you are doing.
So if a user actively _removes_ sysvinit-utils and some package on their 
system break, then they cannot complain. Same for systems created using 
tools like mmdebstrap by forcing a minimal selection of packages. (But I 
don't really like this attitude, so please keep reading and we will deal 
with this.)

So, in this scenario removing Essential may cause some breakage. But, in 
practice, no normal user will see it. (I can tell you as use of 
mmdebstrap+custom package sets, that there similar breakages are 
constantly present.) It will also make the package theoretically 
RC-buggy, but once the MBF and the transition to procps is over, then 
everything will be as good as before (actually better because there will 
be an explicit documentation of the use of pidof via Depends:).

> 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.

That is the aim of the MBF proposed as step 1 of the follow-up plan 
described in the first mail of this bug report: to tell all affected 
packages to add a dependency to the package with pidof. These bug 
reports can later be turned into RC-severity bugs for the last 
stragglers. However, going forward it makes little sense to use pidof 
from sysvinit-utils, Debian should rather use the one from procps. So, 
to avoid having to later change those dependencies from sysvinit-utils 
to procps, the MBF should directly suggest switching to procps.

The cool thing is that, in practice, we don't need the MBF to be over to 
remove Essential from sysvinit-utils. sysvinit-utils is Priority: 
required, procps is Priority: important, so both packages are already 
installed on all normal systems. Adding these explicit dependencies is 
only needed, in practice, to accommodate users of custom installation 
methods like mmdebstrap.

> 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?

I would not worry about this. Upstreams that call pidof at runtime do 
not know which implementation is going to be executed. And given that no 
other big distro ships pidof from sysvinit we can be pretty sure that 
all upstream usages of pidof are compatible with procps. Same for 
upstream-provided init.d-scripts.

Regards,

-- 
Gioele Barabucci