I am currently trying to get the NetBSD pkgsrc collection compile on an
IRIX 5.3 system. As it turns out IRIX 5.3 is really old and seems to
lack many of the features that IRIX 6.5.X must have (judging from the
fact that it is listed as supported for pkgsrc).

Nevertheless my efforts make steady progress (updated details can be
found here: http://geos.maxsyncron.com/netbsd-pkgsrc-on-irix5.3;
feedback would be appreciated), and I have already over 75 packages
installed, being limited mainly by my SGI's speed...

Aside from some issues specific to my situation and OS (e.g.
incompatibility of cc, linker and preprocessor with some code, lack of
c++ compiler) I would like to point out some issues that might be common
for old and non-mainstream platforms, hoping that someone suggests a
solutions to it. Most of these issues with pkgsrc will not surface on
mainstream platforms, so trying to compile it on something really old
seems like a good test of portability to me...

- some packages make certain assumptions about available software that
are not necessarily met. Examples are:

 * security/audit-packages assumes that nroff is present without trying
to install it (or a suitable replacement) if it is not available.
 * archivers/afio needs fnmatch.h (and probably the respective library)
 * many packages (e.g. php) require regex.h (and probably the respective
library)

What do you suggest is the cleanest way to install the necessary code?
Should it be included in pkgsrc To get bootstrap working, I manually
installed a very old GNU regex (0.12) and fetched fnmatch from GNU
inetutils's glob subdirectory. Is there some more elegant way?

- databases/db (and maybe others, too) assumes that CHOWN uses a : to
separate group from user name. With IRIX's chown for example, it should
be '.' instead. It would be a good idea not to hard code it into the
scripts but to use a cofigurable variable like CHOWN_SEP_CHAR for it
(which would default to ":").

- many packages such as bftp or arpd, to name two, use -Wall. If a cc
does not support that they fail to compile. Does pkgsrc offer a clean
mechanism to get around this?

- the output of LDD (defaults to ldd) is piped through awk 'NF == 3
{print $3}'. This implies that meaningful lines (i.e. the ones that list
shared libraries) consist of exactly three columns. I've checked this on
a Linux an a FreeBSD installation, and there it is a total of four
columns, so that output should never match.
IRIX 5.3 BTW does not have ldd at all so I had to write a replacement
script.

- libtool for many packages tells me that -ldl did not resolve any
symbols and could be removed. Does pkgsrc happen to provide an easy
mechanism to do so?

- I am using LOCALBASE=/usr/local/pkg, which is non-standard, but should
work nonetheless. Some packages such as archivers/dar will fail to find
zlib.h for configure, even though the zlib-1.1.4nb1 package is installed
and /usr/local/pkg/include/zlib.h exists.
python22 seems to have similar problems.


- it appears that pkgsrc makes some effort to preserve the PATH
environment variable when doing a su. However, it does not do so with
LD_LIBRARY_PATH. If, as with guspatches for example, zip is being called
in the installation process I have to do bmake install
LD_LIBRARY_PATH=$LD_LIBRARY_PATH when issuing that command as non-root
(evocing su being used). This seems to do the trick.

- it appears that the following code in mk/bsd.pkg.mk is called even
when run-depends-list PACKAGE_DEPENDS_QUICK=true produces an empty
llist:

print-pkg-size-depends:
        @${MAKE} ${MAKEFLAGS} run-depends-list
PACKAGE_DEPENDS_QUICK=true \
        | ${XARGS} -n 1 ${SETENV} ${PKG_BEST_EXISTS}
\
        | ${SORT} -u
\
        | ${XARGS} -n 256 ${SETENV} ${PKG_INFO} -qs
\
        | ${AWK} -- 'BEGIN { print("0 "); }
\
                /^[0-9]+$$/ { print($$1, " + "); }
\
                END { print("p"); }'
\
        | ${DC}

Thus in the xargs chain of commands pkg_info -qs is called with no
pkg-name argument.
Is this intensional?
It produces an error message of the form

pkg_info: missing package name(s)
usage: pkg_info [-BbcDdFfIikLmNnpqRrSsVvh] [-e package] [-l prefix]
                pkg-name [pkg-name ...]
       pkg_info -a [flags]
       
Is this appropriate behavior?  


- pkgsrc checks for some required unarchiver (e.g. unrar) only after
downloading a source file. If for some reason that check fails the
source file has been downloaded unnecessarily. This order might maybe
reversed to optimize things a bit. In general, pkgsrc should first check
whether all required packages are present (or can be successfully
installed) and only then download the current package's source files.

- what about some "basic" software such as man apparently not included
in pkgsrc. Should one compile it directly from the GNU sources?

- what is the cleanest way to set specific compiler optimization
options? (e.g. on IRIX it would make sense to use some -Olimit value
when optimizing) 
 
I am looking foreward to your feedback.
Georg

-- 
Georg Schwarz    http://home.pages.de/~schwarz/
 geos@epost.de     +49 177 8811442