Subject: Re: pkgchk (was Re: today's openssh version 3.7)
To: None <tech-pkg@netbsd.org, bjan+current-users@bjan.net>
From: Martin Weber <Ephaeton@gmx.net>
List: tech-pkg
Date: 09/18/2003 20:27:56
On Thu, Sep 18, 2003 at 01:03:59PM -0400, Sean Davis wrote:
> I like pkgchk, but the problem I have with it is twofold:

> 1) if one build dies, it gives up, often leaving tons of packages
>    uninstalled, with no clear way of knowing what it deinstalled (and thus
>    what you need to redo by hand)

With -o (see below) you'd know exactly where it died. Of course, with -o
it could also tell the dependancy direction before and in which direction
it's deinstalling things, so if it bails out, you know exactly where you are.

> 2) it has the tendency to rebuild things many times. The last time I ran
>    pkg_chk -au, I think I ended up building mozilla something like three or
>    four times. I have > 400 packages installed, and mozilla as we all know
>    depends on about a million other things, but its still very time consuming
>    to build over and over on a 533mhz celeron. I think this is a problem in
>    make update, not pkgchk, but it manifests itself in pkgchk.

And again, I've once implemented a -o(rdered) option to pkgchk, which basically
uses tsort to sort the dependancy list so it builds each package exactly
once ... But it obviously wasn't good enough for netbsd. But that's what
you can be doing. Make a list of <pkg> <dep> pairs, have tsort go over it,
reverse the result and build in that direction. Et voila. I think it's funny
it didn't even get worked on, given that this problem gets reported over and
over and over and over again. Ah well :)

Oh, and it did stop make update'ing, and used make replace instead if there's
things left depending on a pkg which you want to update because it's a dependancy
for something else you need to update, as long as there's just a minor revision
update, and mark the packages depending on the replace'd one somehow so that they
get updated properly once you either do it by free will, or a major revision
change comes in the package (or a minor one, just definition question) -- well
not exactly, as make replace didn't exist then. It just forced a deinstall and
reinstalled stuff then pressing a thumb or two for you so it worked. That could/
should be switchable, too.

-Martin