> 1)  Any way to set the destination of the "gzip'd tar ball"
>     for make package, ie, something with a dirname with the
>     machine architecture (sparc, i386) in it?  Must be some
>     variable we can put in /etc/mk.conf.  I greped thru all
>     pkgsrc/mk/* and didn't find the "gzip'd tar ball" string
>     anywhere, so am at a loss on this one.

set PACKAGES in /etc/mk.conf to the directory. 
 
> 2)  Any way to make packages installed for a DESIRED package
>     be automatically uninstalled, once the DESIRED package is
>     built (assuming that the dependent package is not needed
>     at runtime of the DESIRED package, of coarse).

Don't know, offhand, because I'm a bit unsure what you're
asking.
 
>     Is there any document describing all the targets of the
>     package make system (other than mk/bsd.pkg.mk)?

The Packages.txt document goes some way to doing that.

> 4)  Regarding the Update All issue, it seems that there is
>     no Good Solution.  I think the problem (as was pointed
>     out) is the difficulty of mapping the package name from
>     pkg_info (eg, tex-3.12321321) into its [future] build
>     directory, eg, print/tex.  Chopping off the version
>     number and cd'ing to print/tex-* does work most of the
>     time, but not always.  Clearly, there needs to be some
>     way to store the future upgrade process in the pkg db.

You should also take a look at the "show-downlevel" target,
which will attempt to recurse into every SUBDIR that is
defined (so you could use the *_SPECIFIC_PKGS definitions),
and checks to make sure that the installed package is the
same version as the one in the package Makefile. I've found
the show-downlevel target to be quite useful at times.
 
> 5)  Why is it that when I downloaded a current pkgsrc and I build
>     I need a more recent pkgtools?  I expected that current pkgtools
>     would be integrated into the current pkgsrc, at least around the
>     time of a new release (1.4.2).

Sometimes, new features get added to the package tools. Wildcard
dependencies are a good recent example of this. As pkgsrc is
targetted to all NetBSD versions (within reason), there is no
guarantee which tools you have installed with NetBSD (or Solaris,
or Linux, for that matter). Hence, we provide an easy way for you
to get the necessary package tools for that version of pkgsrc.
Furthermore, it is often the case that there are dependencies
between bsd.pkg.mk and the package tools - again, the wildcard
dependencies spring to mind here - and that is the reason that
checks are made in bsd.pkg.mk to make sure you are using the correct
package tools. The most up-to-date versions of pkgtools have been
pulled up for inclusion in 1.4.2, BTW.

Regards,
Alistair