On Thu, May 19, 2005 at 12:47:28AM +0200, Christian Hattemer wrote:
> Hello dmcmahill@netbsd.org
> 
> On 17.05.05, you wrote:
> 
> > I just checked in some changes to pkgsrc/Makefile, pkgsrc/bsd.pkg.mk,
> > and pkgsrc/mk/scripts/ which should fix this problem robustly.  Please
> > let me know if its better for you.
> 
> Looks very nice. But there are a few issues to resolve.
> 
> The first time I ran it after the cvs update it produced this result and
> hung in the end, eating 100% CPU. Seems it would hang forever if not
> interrupted. (Sorry about the odd word wrap)
> 


> ----> Checking master cache file
> /usr/local/packages/2.0_STABLE/i386/.pkgcache
>       Creating master cache file
> /usr/local/packages/2.0_STABLE/i386/.pkgcache
> cp: /usr/local/packages/2.0_STABLE/i386/.pkgcache: Permission denied
>       Updating master cache file
> /usr/local/packages/2.0_STABLE/i386/.pkgcache
> mv: rename /tmp/pkg-cache.998/.pkgcache to
> /usr/local/packages/2.0_STABLE/i386/.
> pkgcache: Permission denied
> Loading binary package cache file...
> 
> 
> After I made the directories writable all is fine. There should be error
> messages instead of the hang.

ah.  I see the problem there.  This should be fixed now.  I added a fatal
error check looking for the top level cache file.

I also made it a fatal error during the creation of the 
cache files if the copy/mv fails.


> On a minor issue, consider this output of the first successful run:
> 
> ----> Checking master cache file
> /usr/local/packages/2.0_STABLE/i386/.pkgcache
>       Creating master cache file
> /usr/local/packages/2.0_STABLE/i386/.pkgcache
>       Master cache file /usr/local/packages/2.0_STABLE/i386/.pkgcache is up
> to date
> 
> Perhaps the note that the file is up to date shouldn't appear when it has
> just been created before. Also, the ouput of this stage could look like the
> output of the previous cache file stage.

done.
 
> Another longstanding problem which still remains is that the code that
> selects the vulnerabilities for a given pkg from the list is very simple
> and checks only the beginning of the name. With the RegExps nowadays used
> in the list to handle vulnerabilities of multiple related pkgs (e.g.
> mozilla{,-gtk2}) in one line this results to the omission of such
> vulnerabilities in the generated readme.
> 
> To fix this it would probably best to use "pkg_admin pmatch" as bsd.pkg.mk
> does in check-vulnerable.

ugh.  ok, I'll add this to the TODO list.

-Dan

--