Hi Craig, On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote: > Hello, > For quite some time (since 2006!) there has been a discussion at[1] about > changing from the sysvinit-utils version of pidof to the procps one. A > quick scan of the various distributions shows that only Debian and Ubuntu > (and I assume most other downstreams) use the sysvinit-utils version. > > So to rehash some old drafts, here's the proposal. > > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof.
I welcome the effort in general. Like Andreas, I question whether having pidof remain essential is useful. A quick codesearch https://codesearch.debian.net/search?q=%5Cbpidof%5Cb&literal=0 suggests that we have less than 500 source packages that even mention it. Many uses are in test suites or documentation, so the final number will be lower still. If we agree that pidof should not be essential, the next question is whether we need that procps vs procps-base split. Andreas suggests "no". I don't have a strong opinion on that one. Let me suggest an alternative transition plan. We extend sysvinit-utils with a new virtual package "pidof". Then we MBF packages using pidof to add a dependency on pidof. Once a significant portion of those bugs is fixed, we move pidof out of sysvinit-utils and have it drop that virtual package. procps or procps-base can then add pidof (with Breaks+Replaces for sysvinit-utils and Provides: pidof) moving it out of the essential set in the process. Any remaining bugs would be bumped to rc-severity at that point. > Why: > This would bring the pidof variant in line with other distributions. > sysvinit-utils would no longer need to be Essential (though that's a > separate issue) and would only have init-d-script, fstab-decode, and > killall5. I fear sysvinit-utils being essential is not separate (see below). It really needs to be done together, so additionally there would have to be another MBF for those other tools asking to add dependencies. > The majority of usage of pidof is in init or pre/post scripts, which really > should be using the LSB pidofproc function. That function in turn > optionally uses pidof if the pidfile parameter is not given. That's > probably a way forward for sometime in the future to not need procps-base > Essential, but it is a way off. For as long as sysvinit-utils contains /lib/lsb/init-functions, it'll have to include pidof or depend on it. Therefore the pidof provider can only become non-essential once sysvinit-utils is non-essential. If you see the change in implementation as more urgent than making all of it non-essential, then procps-base is needed indeed. > sysvinit-utils requires only libc6 while procps-base require libproc-2 but > this is the same library used for the ps,top,w etc tools which are > installed on most systems. Yeah, please don't increase the essential set. The addition would be very unwelcome to embedded systems. So in essence, you asked for changing the pidof implementation and Andreas and me try to turn this into a much bigger quest of making it non-essential. While these matters are related, they can be done independently in principle and if you do not want to take on the non-essential part, I fear I see little alternatives to that procps-base proposal. Pulling procps-base into the essential set also adds it to the bootstrap set. That also adds numactl to the bootstrap set. I'd rather not have it grown if possible. Both are currently cross buildable, so it's not the end of the world. Helmut
