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

[Andreas Henriksson]

On Fri, Apr 24, 2026 at 09:08:16AM +0100, Andrew Bower wrote:
> 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.

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

I don't want to repeat the "lets add lsb-base dependency to half of all
the packages in the archive and then remove it again" dance.

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

IIRC sysvinit pidof has -z which is not present in procps pidof.

This discussion would however probably fit better on a bug report about
which implementation to use, not on the essential-or-not bug report.

> 
> Thanks,
> 
> Andrew

Regards,
Andreas Henriksson