Subject: Re: Smarter make update / pkg_chk algo
To: Greg Troxel <firstname.lastname@example.org>
From: David Brownlee <abs@NetBSD.org>
Date: 05/26/2005 22:56:09
On Thu, 26 May 2005, Greg Troxel wrote:
> I had already made a hand-written pkgchk.conf that went from less to
> more complicated, so just prepending dependencies was enough for me.
> But tsort is even better (and -g should get this too). Probably
> obvious to you, but this avoids recursive use of pkg_add, and
> therefore needs a lot less PKG_TMPDIR space since only one package
> need be unpacked at a time.
Currently -g does not do any dependency checking - the tsort
would definitely be something to add after a '-g of top
level only packages'
> The man page says "check" about -B, but I think this means "treat as
> mismatch if 'pkg_info -b' output differs".
Yes - I'll update the description to read:
Include the "Build version" (see option -b of
pkg_info(1)) of packages when determining if a
package is up to date.
>> Hmm - if you did not mind the order in which it ran you could
>> just run 'pkg_chk -l | xargs pkg_add -u' and rely on pkg_add
>> to skip those that did not need updating. In fact, with your
>> change to prepend dependencies to the list that should just
>> about cover the order (though ideally a tsort would get it
>> completely right)
> Would need -f, or perhaps pkg_add needs -b to cause -u to treat
> differing build info as differing. Perhaps this should be the
> default, although I think PKGREVISION bumps are supposed to address
> this. But someone might update tiff, notice a shlib bump, and update
> emacs without cvs update, getting a binary package that has the same
> version but really does need to be updated.
>> I use the output of 'pkg_chk -l' directly as a list of files to
>> copy to a remote machine, so the pkg_dir in there would clutter
>> it for me. Would you be happy with an option to display the
>> pkgdir instead of the pkgname, or would you want both?
> Sorry, I meant -i, when generating a list of packages that need
> updating, so I get this:
> devel/popt popt-1.7nb4: version mismatch - popt-1.7nb5
Ah - that definitely makes sense - I'll have a look at it
> (which wasn't particularly machine-parsable to start with), and gives
> me (and scripts) the directory to cd to for 'make replace'. I don't
> want to let pkg_chk kick off make replaces, since I want to bound
> lossage, and for cases like this (absent audit-packages complaining) I
> don't feel the urge to upgrade. It would also be nice to tsort these.
David/absolute -- www.NetBSD.org: No hype required --