Subject: Re: Forcing a full rebuild of GNOME after update from 3.0.1 to 3.1
To: Jeremy C. Reed <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 12/13/2006 17:16:09
On Wed, 13 Dec 2006 15:35:11 -0600 (CST)
"Jeremy C. Reed" <email@example.com> 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
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
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
--Steve Bellovin, http://www.cs.columbia.edu/~smb