Re: pidof changing from sysvinit-devel to procps
On Sun, Aug 11, 2013 at 11:28:47AM +1000, Craig Small wrote:
> On Fri, Aug 09, 2013 at 01:39:20PM +0200, Ben Hutchings wrote:
> > I also wonder whether it would not be more sensible to split procps into
> > essential and non-essential binary packages. Aside from pidof, I bet
> > there are lots of scripts using pkill, pgrep, /bin/kill and ps without
> > the necessary dependency now. (I saw one using ps just the other day:
> > #719126.)
> I happen to think this is probably the best way. There are lots of things
> using pidof and ps in scripts, usually init scripts. (As an aside, this is
> probably wrong; there is a lsb function for this sort of thing; also
> kill `pidof blah` is not nice either). It would come down to what
> is left over and is it worth putting it into another package.
We're getting close to releasing procps upstream which will have the
pidof in it. So its also getting time to work out what to do.
I think I will need to split procps into two binary packages. The first
will have pidof and possibly some other binaries such as ps and would
need to be promoted to Essential
The key thing between the two binary packages is to not pull in
libncurses5w which isn't used by any Essential package currently.
However libprocps would need to be installed as its a dependency
on almost all the binaries.
my first cut of it would be:
procps-base: pidof, ps, sysctl, pgrep, pkill
procps: pwdx, vmstat, tload, free, pmap, skill, slabtop, top, uptime,
watch, w, snice
procps-base is Essential and depends on libc6, libncurses, libprocps,
libtinfo5, lsb-base, initscripts
It will also Replaces and Breaks sysvinit-utils (<< some version number)
as that is where pidof comes from.
procps is not Essential and depends on libncurses5w as well as the above
Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5