Hello!

For various reasons[1], I seem to be spending a lot of CPU time on 
building and rebuilding quite a few packages again and again.
So while watching the make output scroll slowly[2] across the screen, I 
have been thinking...

Often, I want to install a package, but when I discover how much other 
stuff[3] will be sucked in I often change my mind, or delay the 
installation until better times.

I wrote a silly little script[4] I called "desc", which will print the 
description of some packages, along with dependencies, and indicate 
which are already installed, and which are not. I have also made a 
"policy" of postponing installations until absolutely necessary, and 
then reinstalling everything at once, with a freshly updated pkgsrc 
directory tree. I think I began this when I was drowning in a cascade of 
necessary upgrades triggering each other, necessitating a nearly 
complete reinstall anyway.

My script uses the target "show-all-depends-dirs". I don't recall how I 
stumbled upon it. Tonight I learned that this is just a "utility 
target", and therefore not documented? (At least according to 
<http://mail-index.netbsd.org/tech-pkg/2002/09/20/0004.html>.)

I must say, that I think the only valid and permissible excuses for lack 
of documentation are: "I didn't have time" and "I don't care". Either 
one is fine with me. However I'd like to know more about the possible 
uses and abuses of show-all-depends-dirs et al (show-depends-dirs and 
show-all-depends-dirs-excl come to mind): what exactly do they do, and 
can their presence be relied on?

If they really are "internal use only, subject to change", how can a 
user of pkgsrc reliably discover the dependencies of a package? I notice 
that the pkgdep script (which depends on perl5, although I believe it 
would work with any old Perl - it looks like perl4 style to me) looks 
inside /usr/pkgsrc/INDEX to retrieve dependencies. Would that be a 
proper strategy? Can I be sure INDEX is always in sync with the rest of 
my pkgsrc directory tree? My guess is that the make targets are safer - 
in fact INDEX is nonexistent on my i386 machine - but I have frequently 
been wrong about such things. I apologize if I have missed any present 
documentation of this; I have searched what I believe are the obvious 
places, but not found any.

I think the reason for my policy was that, whenever I updated my pkgsrc 
directory tree from the CVS repository, using the documented method, I 
got problems. I *think* this was the reason that branches were 
introduced - but although I can find discussion on the mailing lists 
here and there, I can't seem to find any updated instructions on how to 
deal with the various branches of pkgsrc as a user. Are the pkgsrc 
branches related or synced to the netbsd release branches somehow? Are 
they independent? How do I get them? How do I update them properly? I'll 
happily let you call me a fool, if you could just be kind enough to 
provide a pointer to the relevant information in the same breath.

Anyway, I think I have been using the latest (head?) pkgsrc, with few 
problems.

One problem is, though, that sometimes I wan't to be more picky about 
what to install and what not. While browsing the archives, I noticed 
others have the same feelings. For a while I was the system 
administrator of an IRIX machine, and I think I fell in love with 
"inst". It was really like having a nice waiter, allowing you to combine 
menus with a la carte courses, and telling you which dishes would go 
along well, and which wouldn't, and would you prefer french fries or 
baked potatos, sauce bernaise or bordelaise. After a dialogue to resolve 
any conflicts, just say "go", and inst would go about it's business. No 
further action necessary.

For example, I'd like to order the xfce4 menu. Except the file manager 
is not to my taste, so I'd rather just not have it. As it is, I just 
order the entire menu, and leave the file manager on the plate. This 
means that all the dependencies of the file manager (just an example) 
are installed as well. But I'd have to compute the set difference 
between the xfce4 meta-package and the file manager package to figure 
out which ones I could purge.

I love pkgsrc, and if someone would add a tool to provide this service, 
I'm sure it would become popular. I might try to write one myself - but 
that brings me back to my first question: which way is proper to figure 
out the dependencies of a package? /usr/pkgsrc/INDEX? make 
show-depends-dirs? egrep 'DEPENDS|BUILD_DEPENDS' Makefile?

-Lasse

------
[1] I wanted to install a -current version on my iMac. My iMac runs at 
400MHz. I built and installed current, well actually I cross-built, 
using a faster (?) machine - a 450 MHz AMD K6-2. But anyway, I didn't 
get X to work, and decided to go back to 1.6. Having thrown the working 
1.6.1 system away, I proceeded to build 1-6-release. Right now I can't 
seem to get Mozilla-1.6 to open a window. Different story, which is why 
I only mention it in this footnote.
[2] At least after I got X and XFCE4 built for my iMac. With the 
OpenFirmware console, the word "slow" really is inadequate. Oh, I have 
tried to redirect stdout and stderr, but sometimes I've found that stuff 
wants to go to or even talk to /dev/tty anyway, and redirecting may 
screw up things AFAICT.
[3] I am tempted to say garbage; in any case it's something I have to 
carry along, although I won't be using it directly.
[4] If you insist, and don't tell me how it could be improved:
charlie:/usr/pkgsrc $ cat ~/bin/desc
for i in $* ; do
  echo ;  tput md ;  echo $i ;  tput me
  test -f $i/DESCR && cat $i/DESCR
  pkg_info -Ba |grep PKGPATH >/tmp/inst_pkgpaths
  grep DISTNAME= $i/Makefile
  echo "Dependencies:"
  for j in $(cd $i && make show-all-depends-dirs) ; do
    if grep $j /tmp/inst_pkgpaths >/dev/null 2>&1 ; then
      echo "+$j"
    else
      echo "-$j"
    fi
  done | sort
done |more -r