Some people have advocated using pkg_check to update packages.  I
haven't looked into it, yet.

"make update" has problems, which you will probably hear about (and
certainly you can find out about if you dig a little in the list
archives...(^&).  Despite the problems, I use "make update".

I'm not familiar with the Debian "apt-get upgrade", but from my
previous Debian experience, one big change I'll point out (which
may be obvious) is that pkgsrc is a *source* package system, so
updates go through a build process with attendent issues.  (There
also are binary packages built from pkgsrc.  I haven't used them
much in years and don't know if there's anything comparable for
pkgsrc binary packages.)


Here's how to use "make update", but please read to the end for
caveats:

First, you need to update pkgsrc itself.  E.g., if you have it
set up to track via CVS, you can:

  (cd /usr/pkgsrc && cvs update -PAd)

If you want to update, e.g., the GIMP, you would type:

  (cd /usr/pkgsrc/graphics/gimp && make update)

...assuming that you have installed pkgsrc in the usual /usr/pkgsrc
location.


What pkgsrc will do for "make update" is something like this, as I
understand it, in the particular case of the GIMP:

  It will remove anything that depends upon the GIMP.

  It will remove the GIMP.

  It will look at the things that the GIMP depends upon, and if the
  GIMP requires that any of them be updated, those packages will be
  updated.

  It will then rebuild and reinstall the GIMP.

  It will then rebuild and reinstall anything that you had previously
  installed which depended upon the GIMP.  (Conceivably updating
  things that the current versions of thsoe packages want to have
  updated.)

If all goes well, then updating a single package, such as the GIMP,
can conceivably update many packages, owing to interdependencies of
shared libraries.


CAVEATS:

The general caveat is summed up in the "If all goes well," prefix,
above.  (^&

1) pkgsrc deinstalls before building and reinstalling.  So during the
update process, the package is unavailable.

2) If pkgsrc fails to build the package for some reason, then the old
package will not automatically be installed---you'll just be left with
an uninstalled package and a partial build.

3) Both of the above points apply to any other packages that are inci-
dentally updated by pkgsrc.

4) If pkgsrc fails to update a package that the GIMP "requires" to be
updated, then that will also stop rebuilding the GIMP (and perhaps
other packages).

5) If you feel like taking a chance, you can use "make replace" to
selectively update dependencies.  "make replace" doesn't have as
much (any?) web-of-dependencies impacts, so you can use "make replace"
to avoid the massive rebuilds that "make update" can induce.  The
danger is that some shared libraries change ABIs in ways that they
shouldn't, and you run a non-zero risk of having silently broken
applications if you use "make replace".

6) To protect against potential lossage with "make update", there
are some ideas to use:

 * Use "pkg_info" to generate a list of all of your installed
   packages so that you know what you had/have.

 * Create binary packages so that you can readily revert if things
   crash.  Use "make package" on the package directories, or
   "pkg_tarup" after-the-fact.

 * Create a so-called meta-pkg that has dependencies of all of
   your desired packages so that it can be used to try to generate
   all of the packages that you care about.

 * Use either a chroot environment or a spare machine to test that
   an update will go smoothely (and, then, just go ahead and
   make binary packages while you're at it...(^&) so that your
   "production" machine(s) don't have downtime.

   Rebooting a single computer from a different disk or
   partition is a (dollar-wise) cheap way to have a second system,
   if you don't need your "main" system to be up 100% of the time.

 * pkgsrc has for some time (I don't know how long; I only
   learned this a few days ago) been maintaining the quarterly
   branches.  The quarterly branches are more stable and should
   build with fewer problems.  If you don't need to track the
   CVS HEAD of pkgsrc, then consider following just the the
   most recent quarterly branch for security fixes.


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