Bug#810018: procps: Please (re)consider shipping procps pidof
Gioele Barabucci
gioele at debian.org
Tue May 5 00:00:58 BST 2026
On 03/05/26 21:50, Andrew Bower wrote:
>> The plan:
>>
>> 1. I will announce a MBF on d-devel@, with a request for the 94 packages
>> that use `pidof` at runtime to add `Depends: procps` (the email template can
>> be seen at [2], the dd-list at [3]).
>
> Can I just confirm (as it looks to me) that this covers all runtime
> usage *except* for
>
> a) direct usage in an initscript, and
> b) indirect usage in an initscript via pidofproc where a PIDFILE is
> *not* defined or cannot be reliably guessed?
Hi Andrew,
there are four uses of pidof:
1) at runtime (Depends:)
2) in tests run at build-time (Build-Depends:)
3) in autopkgtests (Depends: in d/tests/control)
4) in initscripts (see #1131136)
This MBF will focus on 1. Two follow-up MBFs will take care of 2 and 3.
(Although there are just a handful of packages in categories 2 and 3. I
believe I'll just send patches instead of doing two proper MBFs.)
>> Does this sound right? Is anything missing?
>
> Considering the above two cases for initscript, which mercifully are not
> as numerous as I first thought, how should we mitigate them?
>
> Here are some options:
>
> 1. [ sysvinit -> procps (global solution) ]
>
> Make sysvinit-(core|utils) depend on procps. (Does not cover runtime
> usage like initless containers.) I would strongly object to this because
> it is too large a dependency to bring in for all sysvinit installations
> or other inits that fall back to initscripts.
> * No thanks *
I see your point, but why shouldn't the package that ships pidofproc
(that uses pidof in certain cases), not Depends: on pidof?
Given that the use of pidof in pidofproc is behind a `-x /bin/pidof`
guard, it should also be OK to accept that pidofproc behaves in a
different way when pidof is not available. This would avoid the
additional dependency on procps.
Another alternative would be changing pidofproc's use of pidof into an
invocation of grep and /proc.
Regards,
--
Gioele Barabucci
More information about the Debian-init-diversity
mailing list