Bug#810018: New Essential package procps-base
On Nov 20, Craig Small wrote: > Also why is killall5 not a candidate too? Probably because it makes no sense outside of sysvinit, except that as a footgun. (Also, is it equivalent to pkill --inverse?) -- ciao, Marco signature.asc Description: PGP signature
Bug#810018: New Essential package procps-base
On Wed, 15 Nov 2023 at 23:03, Guillem Jover wrote:
> I'm all in for shrinking the essential-set. If there is consensus to
> switch pidof implementations that also seems fine to me in the abstract.
> But this shuffling around of essential-ness and new tiny packages and
> stuff seems a bit unnecessary to me, more so when this increases the
> bootstrapping-set. I'd also rather see instead a _proper_ transition to
> get sysvinit-utils out of the essential-set, and then at some later
> point procps can take over pidof.
>
There really is two options then:
1) Switch pidof to new Essential package procps-base THEN update/fix the
dependent packages
2) Update/fix the dependent packages THEN move pidof to standard procps.
Independent? of either: re-work init scripts to use start-stop-daemon
For people that want the standard pidof #1 is preferred, for people
concerned about Essential's size #2 is preferred.
Most of the pidof usage can be broken down into a few sets:
* Used in comments/documentation - can be ignored for "pidof is Essential"
purposes
* Used in init or pre/post scripts - should probably be using pidofproc
* Within their programs use something like system("pidof myprog")
and then there are a few other odd ones that don't fit into those three.
Then there's the following, which I guess complicates things:
>
> $ dpkg -S bin/pidof | cut -d: -f2
>/bin/pidof
>
I'm not sure what the complication is here.
Also why is killall5 not a candidate too?
There's no other implementation of killall5 though it is probably something
that could be done with one of the other /.*kill.*/ programs.
Significantly, I don't think there is any real dependency of this program
in other programs, codesearch seems to be only for documentation.
> I think the status_of_proc function could be switched to use
> start-stop-daemon (s-s-d) --status instead of pidofproc. To replace
> pidof inside pidofproc I guess s-s-d could grow some option to print
> the pid, I'd be happy to implement that. After doing a quick scan over
> codesearch.debian.org, I notice that it looks like many current uses
> of pidofproc should instead probably be using status_of_proc, and others
> seem to just be fetching the pid to then perform some action that could
> instead all be done directly with s-s-d.
>
I agree that this is a good idea. It will be more about removing the
Essential flag on any package.
- Craig
Bug#810018: New Essential package procps-base
Hi! On Tue, 2023-11-14 at 17:29:01 +1100, Craig Small wrote: > 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. > > 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'm all in for shrinking the essential-set. If there is consensus to switch pidof implementations that also seems fine to me in the abstract. But this shuffling around of essential-ness and new tiny packages and stuff seems a bit unnecessary to me, more so when this increases the bootstrapping-set. I'd also rather see instead a _proper_ transition to get sysvinit-utils out of the essential-set, and then at some later point procps can take over pidof. Then there's the following, which I guess complicates things: $ dpkg -S bin/pidof | cut -d: -f2 /bin/pidof Also why is killall5 not a candidate too? In any case the pidof CLI interface does not seem too big, so this does not feels urgent to me, given the trade-offs. > 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. I think the status_of_proc function could be switched to use start-stop-daemon (s-s-d) --status instead of pidofproc. To replace pidof inside pidofproc I guess s-s-d could grow some option to print the pid, I'd be happy to implement that. After doing a quick scan over codesearch.debian.org, I notice that it looks like many current uses of pidofproc should instead probably be using status_of_proc, and others seem to just be fetching the pid to then perform some action that could instead all be done directly with s-s-d. Thanks, Guillem
Bug#810018: New Essential package procps-base
On Tue, 14 Nov 2023 at 10:13, Helmut Grohne wrote: > 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. Yeah, let's not make this task impossibly huge and lengthy, please. Using the same implementation as every other distro has immediate benefits for everybody, packagers and users. Rearranging the packaging details and priorities and whatnot is pretty much an internal-only detail - which doesn't mean it's not good or useful or worth doing, just that I don't think it's worth blocking the first part for it, as it can happen just as well later. The procps-base proposal looks good to me.
Bug#810018: New Essential package procps-base
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=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
Bug#810018: New Essential package procps-base
Hello, 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. I support using procps implementation in Debian, to align us with the rest of the world. > > 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 however do not think pidof needs to be part of the Essential set. Instead I think pidof can just be part of procps package. The sysvinit-utils package will then pull in procps via a dependency (once sysvinit-utils stops being Essential), which would smooth the transition for all sysvinit users until LSB pidofproc has been implemented in all init scripts. > > 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. > > 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. Additionally most uses of pidof is `if pidof [...]; then` which will expand to false/else when the pidof command is not available (which it should be on all "normal" systems, as procps is already Priority important). A number of years ago I tested booting a regular debootstrapped system (with all priority important packages, etc) with sysvinit-utils excluded and that did not show a single warning about missing pidof. Someone might want to repeat that experiment. > > 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. > > > 1: https://bugs.debian.org/810018 Regards, Andreas Henriksson
Bug#810018: New Essential package procps-base
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. 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. 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. 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. 1: https://bugs.debian.org/810018
