On Wed, 13 Dec 2006 15:35:11 -0600 (CST)
"Jeremy C. Reed" <reed@reedmedia.net> wrote:

> > To get a list of packages I have installed and want to keep, I do:
> > pkg_info -B -a |grep PKGPATH|sed 's/PKGPATH=//' >pkgs_i_want_to_have
> 
> You can also use:
> 
> pkg_info -Q PKGPATH -a > pkgs_i_want_to_have
> 
> On my system it is at least five times faster.
> 
> I am working on a wiki about upgrade ideas at
> http://wiki.netbsd.se/index.php/How_to_upgrade_packages
> 
I plan to contribute to that Wiki; many thanks for setting it up.

The problem with both of those suggestions is that they give the wrong
information.  What I really want is a list of the packages I explicitly
built.  Leaf packages are an approximation (and there isn't even an
option to list those, though a script is reasonably easy to write), but
that drags in build-time tools that aren't needed at run-time.  More
precisely, they aren't desired by the user.  The list may change over
time.  Some of the change may be due to build patterns changing -- gtk1
to gtk2? -- but more, I suspect, is due to people changing their minds
about what they want.  That is, if I install foo/bar some day, it may
drag in devel/libxyzzy.  I may delete foo/bar, when I find it doesn't
do what I want; that won't delete devel/libxyzzy.  OTOH, when I do a
bulk rebuild (and I do those periodically...), devel/libxyzzy will go
away.

My wish list, then, is this:

a) Top-level 'make install'/'make package' commands should
create an entry in some database.
b) Lower-level 'make' commands should not create this entry.
Presumably, the top-level 'make' would create an environment variable
as a flag.
c) When a package is deleted, its database entry is deleted.  

Some bells and whistles that would be nice would be if there were a way
to delete, recursively, all packages it requires; these deletions will,
of course, fail if there are other packages that depend on them.  It
would also be nice if it tracked the build-time requirements *that had
to be built for it*, so those could be deleted.  I stress the condition
because I don't want to delete, say, Perl just because it was one of n
tools needed to build some package.  (Corollary: the deletion list
generated by this step should be an output list suitable for feeding to
pkg_delete; that makes it easy to hand-edit.)

a-c seem easy enough, but I'm frankly scared to touch the pkgsrc
infrastructure myself.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb