Hi,

I am in the middle of upgranding a pkgsrc-2006Q1 installation to 
pkgsrc-2006Q3, working with pkg_chk 1.81 and binary packages from a 
local bulk build.

Unfortunately, pkg_chk behaves strangely, in the sense that I get, 
errr, results that I do not remember from a previous upgrade run.

I started by setting

# pkg_chk(8)
setenv PKGCHK_CONF              ${HOME}/pkgchk.conf
setenv PKGCHK_UPDATE_CONF       ${HOME}/pkgchk_update-`hostname -s`.conf

[Why no commandline option for those? No '/usr/pkgsrc' on a 
binary-only system.]

and created an initial pkgchk.conf list from the existing installation with

[1]  pkg_chk -b -g -u -q -P /misc/pkg-new/All -L ~/pkgchk.log

The logfile had a few packages missing which I built manually (like 
the Sun JDKs which you have to download manually), and a few packages 
that were either renamed or made obsolete.

I added some new packages to, and removed stuff from, the generated 
pkgchk.conf, and invoked

[2]  pkg_chk -u -a -b -C ~/pkgchk.conf -P /misc/pkg-new/All -L ~/pkgchk.log2

which is supposed to replace the installed packages with their newer 
equivalents. So far, so good.

Apparently, it started by listing the currently installed set of 
packages in $PKGCHK_UPDATE_CONF, and somehow merged that with the 
file under $PKGCHK_CONF.

[Short of removing them beforehand, you have no way of telling 
pkg_chk to just ignore packages that are non-existing, or renamed, or 
superseded by others? The config files, and how pkg_chk uses them, 
are mostly undocumented in the man page. No "typical use" examples 
there, either.]

Eventually, the pkg_chk run died because or some conflict. I resolved 
that by removing one of the packages (cdrecord, iirc), and restarted 
pkgchk. Strangely enough, it would then print a lot of lines of the 
form

[3]  some/package package-a.b.c < package-a.b.c (binary package available)

-- pkg_chk did not recognize that the version it wanted to update to 
is already installed. And then it proceeded to remove all (AFAICS) 
the packages, and re-installed them. It didn't resume, it started 
from scratch.

At the end, I got a "Missing:" line listing packages that were gone 
for good, and a long "Failed:" line, basically listing a lot of 
packages that a pkg_info(1) showed as properly installed, and at the 
current version.

[It looks to me that pkg_chk tries to perform magic, and gets 
seriously confused on the way?]

This was repeatable - run [2], and watch it de-install everything, 
and install in the same versions. So, I re-created the pkgchk.conf by 
running [1] against the (to an unknown extent) updated set of 
packages, and again got output like [3]; but this time there was no 
"Failed:" output beside the "Missing:" line.

Now, it would seem that I have gotten somewhere. It is just that from 
the behaviour of pkg_chk I cannot assume with confidence that this 
installation is up-to-date, or even, that it has the same set of 
packages as before. Unless I start to manually, and tediously, 
compare five-hundred-line package lists, that is.

The obvious question: Is there an easier way?

Why does pkg_chk do its thing in such an obscure way, with such 
confusing and misleading output? Where does "feature" end, and "bug" 
begin? I'd expect some kind of before-after summary - there is 
nothing of the kind.

Am I missing anything obvious? I can restore the system (Radmind 
rules!) and run the update again, if there is anything I should try 
or change.

Comments?

	hauke

-- 
/~\  The ASCII Ribbon Campaign                    Hauke Fath
\ /    No HTML/RTF in email	        Institut für Nachrichtentechnik
  X     No Word docs in email	                  TU Darmstadt
/ \  Respect for open standards              Ruf +49-6151-16-3281