Hi Gioele, On Tue, May 05, 2026 at 01:00:58AM +0200, Gioele Barabucci wrote: > 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)
#1131136 has converged on specifically the removal of sysvinit-utils from the essential set and, with pidof dependence brought forward to this bug (should we add a blocking relation?), only runtime reliance on the lsb helper scripts remains as an obstacle. With the latest proposal (i-s-h) there I hope something that should be good for everyone, we can hopefully move forward on that bug! I agreed with you (although not everyone was convinced) that in that case making init environments responsible for the runtime environment where such scripts are needed would have been a tolerable compromise at the expense of an unknown number of applications of the initless container use case for initscripts, which could in any case never be a guaranteed mode of operation. But that is in the context of a dependency on the lightweight sysvinit-utils. It would be quite different to require a dependency on 2M procps for all installations of sysvinit-core (and other inits) and directly hit the class of use case for which this reduced Essential set exercise ought surely to be targetting, say a lightweight VM. That would really weight on the cost side of the cost-benefit analysis here. > 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? If my analysis is correct in my last e-mail, there are only three packages that would actually be affected by the indirect usage of pidof via pidofproc(), so the other <35 packages that directly invoke it are the ones that will need the dependency (my mitigation #2) except in the cases we are able to do something better for that package (mitigation #4 or your final suggestion below). > 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. Andrew
