Hi Craig,
Post by Craig SmallHello,
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.
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.
Post by Craig SmallThis 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.
Post by Craig SmallThe 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.
Post by Craig Smallsysvinit-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