Re. http://mail-index.netbsd.org/netbsd-users/2003/09/17/0003.html

(That's an interesting email address, Louis.  (^&)

After a few years around NetBSD, I've come to a few conclusions about updating
packages.

 * If it ain't broke, don't fix it.

 * If you're going to fix it anyway (or if it *is* broke), then only fix
   it when you can afford to have it, and perhaps half of your other packages,
   *really* broke.

 * Use "make package" (is there anything that combines "make package" and "make
   update"?).

 * Keep a list of the packages that you really care about, or at least
   a list of installed packages prior to an update.  (I should do this, but
   seem to manage not to---I update pkgsrc only very rarely, and forget
   about this one.)  This can be a useful guide if your package update blows
   up...  (If you muck around in the pkgsrc .../work directories, you can
   manually extract this info, but it's neither centralized nor (I think)
   documented.  So keeping your own list is pro'ly a good idea.)

 * Another good idea may be to update pkgsrc via CVS, then wait a week
   to see if anyone reports breakage on tech-pkg or in a send-pr.  If
   it looks okay, then build from the week-old pkgsrc.  (I haven't gone
   this route, because I usually have some specific and immediate interest
   or need when I update pkgsrc.)

You can probably ignore these points if you only have a few small packages.
But once you install some of the bigger ones, you end up with a ton of
libraries and sub-packages.  Then, updating an innocuous-seeming package
can update one of your libraries, and suddenly it seems that half of your
packages are lying on the floor.  Then, all too often, ONE of the packages
that your system is trying to rebuild will fail, and the whole update
process grinds to a halt.

I've been burned by that in the past a few times...


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/