Subject: Re: apr0/apr naming scheme not getting along with pkg_chk (hard problem)
To: Todd Vierling <firstname.lastname@example.org>
From: Greg Troxel <email@example.com>
Date: 02/08/2007 12:18:01
This happens because devel/apr was bumped to 1.2.8, but the old
version moved to apr0. If you do a "make replace" on apr0 by hand,
this will fix itself (because the new pkgsrc subdir will be recorded
in the rebuild).
Thanks; that makes sense and I didn't realize where the dir was coming
from. After I did make replace in devel/apr0, pkg_chk indeed reports
that no upgrades are needed.
pkg_chk uses the PKGPATH variable in the +BUILD_INFO for the package
to determine the source of the original package build. Thus it's
physically incapable of knowing that a package moved.
True, but I still think this is a bug in the overall pkgsrc system.
With the caveat that "make replace" is not reliable, and even says so
when you use it (which is why it should always be done with manual
That's true, but I find that with the unsafe_depends marking and
subsequent rebuilds it is actually entirely reliable if it succeeds,
and on balance more reliable than 'make update', which has the desired
safety properties (no unsafe depends) but not the liveness properties
(system will run) everyone wants. So, I've been trying to think about
how to make the make replace path better. pkg_rolling-replace and the
marking with unsafe_depends is the biggest step.
So, it would be cool to have an upgrade database so that branch
changes like this could be handled more gracefully. Had
subversion-base and www/apache been able to build with apr1, it would
have been fine - just a temporary period of things not working. So
the real problem is in apache-land.
Greg Troxel <firstname.lastname@example.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)
-----END PGP SIGNATURE-----