Subject: Re: pkgchk (was Re: today's openssh version 3.7)
To: Sean Davis <dive@endersgame.net>
From: Chris Wareham <chris.wareham@iosystems.co.uk>
List: tech-pkg
Date: 09/19/2003 09:28:16
Sean Davis wrote:
> On Thu, Sep 18, 2003 at 09:45:38AM -0700, Bruce J.A. Nourish wrote:
> 
>>On Thu, Sep 18, 2003 at 12:23:21PM -0400, William Allen Simpson wrote:
>>
>>>I'm suggesting automated fetching and installation of binaries, on the 
>>>order of (similar to other projects):
>>>  pkg_update
>>>  pkg_upgrade
>>
>>pkgtools/pkgchk
> 
> 
> 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)
> 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.
> 
> 

If pkg_chk dies, then it leaves behind a file called .DDIR (if memory
serves) in the working directory of the package it was updating. This
lists the packages that would have been reinstalled after the current
one was updated. In fact, if you fix the problem that caused the build
failure and issue "make update" then all the packages listed in .DDIR
will also be rebuilt.

Making pkg_chk more intelligent by constructing a tree of dependencies
would be nice, and there is another package tool that constructs such a
dependency tree. If someone has the time to merge the necessary bits
into pkg_chk that would be great. Findind someone with the time to do
the work is the problem ...

Chris
-- 
chris.wareham@iosystems.co.uk (work)
chris.wareham@btopenworld.com (home)