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

[Andrew Bower]

Hi Gioele and others,

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.

> > 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
> 
> My analysis covers autopkgtests and the MBF will include 11 packages whose
> autopkgtest control file will have to be fixed. (I haven't spoken much about
> the details of the MBF because they do not matter until there is agreement
> about the overall plan.)
> 
> What my analysis do not cover are cases of programs a) running
> init.d-scripts b) at runtime (outside build-time tests and autopkgtests) c)
> in a system that uses systemd. I do not know if such programs exist. If they
> do, they probably already have measures in place to be able to run in
> distros that do not support sysvinit at all. And for the couple of programs
> that don't do, they will be flagged by their users and their dependencies
> will be patched in unstable. Are any such programs known?

I don't know of anything specific and agree any cases in the archive can
be handled as found.

Personally I was mostly concerned about the impact of helper scripts not
being present and making sure it remains low friction for package
maintainers to (helpfully) carry initscripts with their services. I am
convinced that this transition will be OK from this perspective,
although I don't write for anyone else.

Did anyone identify the different command line options of procps's pidof
for the benefit of this thread? I have a feeling this command is not
infrequently used in third party software, but of course the affected
options might be niche.

Thanks,

Andrew