[Pkg-sysvinit-devel] procps with pidof is released

[Steve Langasek]

[sending this to both pkg-sysvinit-devel and debian-devel, instead of having
two separate threads.]

On Mon, Dec 09, 2013 at 01:49:37PM +1100, Craig Small wrote:
> On Sun, Dec 08, 2013 at 06:56:57PM +0000, Roger Leigh wrote:
> > That sounds fine, I think.  So on the sysvinit-utils side, we simply
> > drop pidof?
> Yes, and the man page too.

> > Will procps-base be guaranteed to be installed via upgrade?
> Now this I am unsure. It will be Essential but do new Essential packages
> automatically get installed?

> > I imagine we'll have to also have a depends on
> > procps-base >= 3.3.9-1 to ensure pidof is available at all times
> > during the upgrade?
> That depends on how Essential is handled.

> > To ensure proper upgrade ordering, should the
> > procps-base Breaks also be a Conflicts?  (I mean, we want to avoid
> > a window where any other packages/maintainer scripts need to use
> > pidof but sysvinit-utils is upgraded but the new procps-base is not
> > yet unpacked)
> I don't think so. I'm not an expert at how dpkg works but I thought if
> procps-base Breaks sysvinit << X.Y.Z then if sysvinit X.Y.Z is there
> it won't get installed.

Neither Conflicts nor Breaks; only Replaces.  And sysvinit-utils needs to
Pre-Depend on the new procps-base.


Incidentally, AFAICS the pidof implementation in sysvinit appears to be
built into the killall5 binary which we still ship and which you did not
mention being part of procps-base.  So in practice, this change doesn't
appear to actually save us any code in sysvinit, which makes me wonder why
we're making the change at all.  You said that this was a result of
discussions with "sysvinit-tools upstream".  Who is that upstream, and where
did this discussion take place?  Note that the upstream for our sysvinit
package in Debian is <http://savannah.nongnu.org/projects/sysvinit>, which
is not called "sysvinit-tools", and the sysvinit-devel mailing list doesn't
show any record of this discussion.

AIUI, you've also proposed including the following list of binaries in
procps-base:

 > procps-base: pidof, ps, sysctl, pgrep, pkill

Currently, the *only* one of these which is used as part of the essential
set is pidof.  Why would you put any of the rest of these in an essential
package, given that you already have a binary package split between the
Essential: yes procps-base and the Essential: no procps?


Given the lack of discussion on sysvinit-devel and the unclear references to
"sysvinit-tools", I fear that we may be adopting a complicated transition
for reasons that are actually completely unrelated to Debian's upstream.
The procps mailing list thread[1] suggests this is about killing off
"sysvinit-tools" in Red Hat.  Well, that has nothing to do with us, and
moving pidof around certainly doesn't kill off sysvinit-utils for us (there
are still over a dozen other tools in that package in Debian).  So why
should we make this transition at all?  AFAICS, the better solution here is
to ignore the pidof binary from procps upstream and leave the existing
packages alone.

[1] <http://www.freelists.org/post/procps/Adopting-pidof-from-sysvinittools,6>


> > Just to double-check: the new pidof is completely compatible with
> > the old?
> It's compatible in how it is called in Debian. There are some flags
> dropped but we never had them in the first place. It is a complete
> re-write by the sysvinit maintainers but they needed to move it out
> of that package; I assume its to do with upstart/systemd/whatever
> situation that all distributions are struggling/debating/arguing
> about.

It looks like you're talking here not about the sysvinit maintainers, but
the *Red Hat* sysvinit maintainers.  Perhaps the rewrite of pidof is
something that we want to pick up, but the rationale for including it in the
procps package doesn't apply to Debian at all.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20131209/b8544349/attachment.sig>