On Fri, 2 May 2003, Thomas Klausner wrote:

: Nick Hudson <skrll@netbsd> recently updated pth to 2.0.0
: but ran out of time, so I finished the PKGREVISION bump work
: that was made necessary because of the pth library major bump.

Um, that's just wrong--since you did not update the dewey DEPENDS on pth,
you should not have bumped PKGREVISION on dependent packages.  Basically,
you've just marked perfectly legit packages as out of date for no reason,
since the old pth is still considered valid by pthread.buildlink2.mk.

Let's say that pth-1.4.1nb5 is installed already, as required by
pthread.buildlink2.mk (and some other package already installed on the
system).  So I decide to go build databases/openldap, which needs threads.
I now get openldap-2.0.27nb3, which is not using pth-2.0.0, and thus
contains identical binaries to those produced by openldap-2.0.27nb2.

Now, were I to make a binary package of the above openldap pkg for use on my
other boxes, it would still have the dependency on pth>=1.4.1nb5, even
though the PKGREVISION bump was supposed to differentiate pth dependency
versions.  Huh!?

The way to fix this is not to bump PKGREVISION at will:  instead, it's
necessary to have binary packages prefer a specific set of package versions
and/or use a shared library lookup system (yes, this is where RPM has an
advantage, and has been a known pkgsrc problem for a long time).

-- 
-- Todd Vierling <tv@pobox.com>