Jonathan Belson writes:
> 
> My problem is with the package system - I downloaded some
> packages from ftp.netbsd.org, and while some install
> with pkg_add quite happily, others either do nothing (ie.
> pkg_add just returns with no message, even with the -v option)
> or get as far as CWDing but then stop.
> 
> Are there any known issues with the current package system?
> Any clues as to what could be going wrong?  It's can't be just
> a disk-space thing, as 'top' wouldn't install.

I don't know about "known" in the global sense, but I ran into a
hassle and fixed it.  I found that the pkg_tools couldn't handle
a symlink in any part of the path you were installing into, or
indeed, any path that it inspects for any reason.

Eg: I always build a system with just root and /usr partitions,
then I symlink /var to /usr/var to prevent problems with root
filling up.

But pkg_add will silently quit rather than install packages because
/var/db is now gotten-to via a symlink.  The whole reason for this
recalcitrance is because pkg_add's author chose to use lstat(2)
rather than the more reasonable stat(2).  Why?  Maybe he has a
reason, but it breaks it as far as I'm concerned.

Apply this patch, and pkg_nirvana is reached :-)


# This patch applies to pkg_install/lib/file.c
# It fixes the problem that causes pkg_* to fail working in folders
# that are symlinked (eg: if /var is symlinked to /usr/var)

--- file.c.org  Sun Nov  1 19:27:08 1998
+++ file.c      Sun Nov  1 19:26:52 1998
@@ -53,7 +53,7 @@
 {
     struct stat sb;
 
-    if (lstat(fname, &sb) != FAIL && S_ISDIR(sb.st_mode))
+    if (stat(fname, &sb) != FAIL && S_ISDIR(sb.st_mode))
        return TRUE;
     else
        return FALSE;


Cheers!

-bmw