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

[Gioele Barabucci]

Hi Andreas,

On 24/04/26 12:53, Andreas Henriksson wrote:
>> On Sat, Apr 18, 2026 at 09:52:25PM +0200, Gioele Barabucci wrote:
>>> I believe my analysis <https://bugs.debian.org/1131136#18>, in particular of
>>> Scenario A, addresses all your points (except one, see below). Feel free to
>>> point out parts that you find wrong or problematic.
>>
>> Thank you for your effort to make sure all use cases are considered!
>>
>>> On 18/04/26 15:45, Andrew Bower wrote:
>>>> 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},
>>>
>>> That is not needed. As described in Scenario A, init.d-scripts run in an
>>> environment in which sysvinit-core is installed, and it brings in everything
>>> that is needed to run init.d-scripts, including sysvinit-utils (that is
>>> Priority: required anyway).
>>
>> Yes, as I continued, IMHO it is preferrable to have an indirect way of
>> expressing this environment-specific dependency rather than doing the
>> above.
>>
>>> Counterargument: Should all packages that ship an openrc file also Depend on
>>> openrc?
>>
>> At present, I don't believe any packages ship openrc integration other
>> than fallback initscripts because they don't have an overriding
>> directory where they can use the openrc interpreter. (I expect that
>> openrc users will want to add such a thing in due course so they can get
>> the full benefit of openrc.) So packages won't need to change but openrc
>> will need to gain a dependency on sysvinit-utils, obviously.
> 
> Having the dependency in a few more central packages (instead of in
> every leaf package) would make it easier to switch to a different
> package potentially providing pidof in the future,
> which I personally think would be nice (if that ever happens).

if I understand correctly, Andrew's point is not related to /bin/pidof 
but to /usr/lib/{init/init-d-script,lsb/init-functions}.

Andrew's reasoning is that (Andrew, please correct me if I'm wrong), 
once sysvinit-utils is no longer Essential, every package that ships an 
init-script should Depends: on sysvinit-utils because init-scripts 
should be able to run in any environment (also where init=systemd) as 
normal programs. Given that many init-scripts require 
/usr/lib/init/init-d-script, the packages that ships them should ensure 
that that file is available ⇒ Depends: sysvinit-utils.

My position is: not all packages that ship an init-script should depend 
on sysvinit-utils. Why? Because init-scripts are not run-time components 
of upstream programs (except a handful of cases that will, in fact 
require Depends: sysvinit-utils). If a user (not a program) wants to run 
an init-script, they must take care of making available everything that 
the init-script requires. That means installing at least sysvinit-core 
or -utils.

BTW, sysvinit-utils will still be "Prio: required" for at least a 
release, so no breakage will happen in standard installations.

A final analogy: adding sysvinit-utils to the Depends: of a package just 
because it ships an initscript seems to me as wrong as making a package 
hard-depend on `foo` just because `foo` is needed to run one of the 
examples in the documentation.

Regards,

-- 
Gioele Barabucci