On Mon, Mar 21, 2022 at 02:01:14PM +0100, Andreas Henriksson wrote: > On Mon, Mar 21, 2022 at 10:34:58AM +0000, Mark Hindley wrote: > > Craig, > > > > Thanks for this. > > > > This dates from before my detailed involvement with this area of Debian. I > > have > > read through the bug report, but apologies if I have missed pertinent > > detail. > [....] > > 3) A desire to reduce the Essential set. > > > > I understand and appreciate the general motivation for this. However, > > moving > > pidof to procps would make procps Essential and it is already about 20 > > times > > bigger than sysvinit-utils, so it does not achieve the aim. > [...] > > I don't see why you think pidof (and thus entire procps) must be > Essential. That would indeed be counter-productive. (I haven't re-read > the discussion, but I'm pretty sure we already covered this.) > > As I've already proven elsewhere sysvinit-utils (with or without pidof, > which AFAIR is the only semi-useful utility left in that binary package) > can be made non-essential without any problems already. > > > What do you think? > > I think apart from reducing the essential set, it is also useful to > eliminate pointless differences. > > The distributions I've looked at (that are not just following along as a > debian derivate) uses procps pidof already.
Exactly. And there have already been issues in which pidof's behavior changed in unexpected ways because of the needs of sysvinit (e.g. https://bugs.debian.org/926896 ). Decoupling the two makes such issues less likely, and removes the one way in which systems not otherwise using sysvinit have a dependency on sysvinit components. I wouldn't expect procps to become essential; ideally packages that use pidof in scripts would add an appropriate dependency. (This would help people building minimal containers/chroots.) But orthogonally, I think there's value in migrating pidof to procps.
