Subject: Thoughts (rambling?) about pkgsrc, dependencies, branches, and documentation
To: None <firstname.lastname@example.org>
From: =?ISO-8859-1?Q?Lasse_Hiller=F8e_Petersen?= <email@example.com>
Date: 04/13/2004 02:42:07
For various reasons, 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 across the screen, I
have been thinking...
Often, I want to install a package, but when I discover how much other
stuff will be sucked in I often change my mind, or delay the
installation until better times.
I wrote a silly little script 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
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
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?
 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.
 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.
 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.
 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
for j in $(cd $i && make show-all-depends-dirs) ; do
if grep $j /tmp/inst_pkgpaths >/dev/null 2>&1 ; then
done | sort
done |more -r