There are a few problems of course, but you are not quite clear about
exactly what part of the process bit you.

The most grievous problem, in my eyes, is that if the build fails
on one package in the middle, you wind up with approx. half of your
packages disemboweled on the floor.  Restoring them is a pain.

The second problem is a bit smaller, but is real: The first step that
pkgsrc takes is to delete the current version during an update.  The
package is not available again until the build completes.

(Well, as Jeremy asks: Did it complete successfully while failing
to rebuild any of your old packages?)

A rare problem, which I think is rightly called a bug with the
affected packages, is when your system is trying to rebuild a package
that was removed, but which conflicts with a newer version needed
by some other package.  I've had this happen perhaps once.


There are several ways to deal with these problems; some are
more helpful than others but you might consider any of them:

 * Do something like "pkg_info >/var/pkgs".  Now you have a list
   of extant installed packages.  If things blow up, you at least
   have some help in restoring things.

 * The new "pkg views" system is supposedly able to cope with this
   by letting you do a build without deleting prior versions.
   I don't know if support for that will, or can, be made default.

 * A simple, robust way is to simply have a spare system similar to
   the one on which the main packages will be installed.  Use it
   to verify that pkgsrc is in a consistant state for the packages
   you want before attempting to update your installed system.

 * Download, or build your own, binary packages.  E.g., "make
   package" instead of "make install", next time.  Even if a
   new pkgsrc update blows up, you can always revert to binary
   packages from before and reinstall working software.

 * Note the dates on which you CVS update your pkgsrc, so that
   you can get back.

 * Use "make replace" on key libraries that you know or
   suspect will need to be updated.  (Note that this is a
   bit dangerous, but lets you get the library updated
   without rebuilding everything that it requires.)

   You can more generally use "make replace", but it
   does not recurse through dependancies.

 * Avoid "bloatware" packages that have a ton of dependancies
   and which are themselves huge hulking monsters (KDE, GNOME,
   and a couple of others come to mind).  These packages not
   only take a lot of resources to compile (and run), but also
   are intertwined with many many other packages, which can cause
   a cascading effect.  (E.g., if you update something that
   KDE uses, KDE will need to be updated.  KDE may then require
   the latest PNG---which had a security fix or two in August---and
   that will force updating many other things.)


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