Returning with question about SELECTIVELY updating ports tree

[b. f.]

> > Protect your ports tree
> > $> cd /usr/
> > $> mv ports ports_save && mkdir ports &&
> > portsnap extract
> >
> >
> > This way you have your old and a fresh ports tree
> > available.
> > Portsnap checks the file ports/.portsnap.INDEX to see
> > which
> > ports have updates without this file portsnap extracts the
> > whole tree.
> >
> > Now you can check with diff what has changed in your
> > needed
> > ports. In most of the cases you can merge the ports in the
> > saved tree to newer versions.

> When you do that, don't you mess up the "install/uninstall" data?  The new port
> may not know how to uninstall the old one correctly, or even understand that the
> old one is installed.

This only happens infrequently, when a port is moved or removed, and
this is almost always recorded in ports/UPDATING, ports/MOVED, or
both. For these rare cases you can call pkg_delete(1) manually (the
'deinstall' and 'deinstall-all' targets for the port are just wrappers
around pkg_delete), or  or use portupgrade or portmaster with the -o
flag.The records of installed ports are kept in the package database
directory (usually /var/db/pkg), and are independent of the ports
tree.

>
> Or am I missing something?  I went through something like this a while ago, with
> a massive set of uncontrolled rebuilds.  My shared libraries and executables
> were bolixed and after two days of trying to get X (and X apps and other things)
> running again I gave up and reloaded from backup.
>
> I don't want to go that route again.
>

That's understandable, but if you do the upgrade properly, it may be
less trouble than maintaining a hybrid ports tree on your own.  If
you're willing to take the system down for a period, the instructions
for a complete upgrade in the portmaster(1) manpage from the
ports-mgmt/portmaster port are reliable.  And you could use packages,
at least as an intermediate step, which would make an upgrade much
shorter, or at least minimize the downtime.  Your version of FreeBSD
is not so old that it should cause many problems with newer ports,
since the default packages are built on 7.1-STABLE.

> Here's my point of confusion:
>
> My understanding is that portupgrade understands how to rebuild ports and manage
> their dependencies.  It's not perfect, but it's far more right than wrong.  And
> the key to portupgrade is whatever ports-available/dependent list it uses.  So
> shouldn't The Right Thing To Do be to fetch and install just the upgrade to that
> list?
>

The list is the index. Most people just download a copy of the index
from the FreeBSD package repository, which lists the ports available
in a recent snapshot of the ports tree, with dependencies based upon
the default choices for options that are used to build packages there.
 You can run into problems when your index isn't synchronized with
your ports tree and the options stored in the ports database directory
(usually /var/db/ports), or in local Makefiles.  This might happen
with your partially-updated tree.  So it would be safer to build your
own index, by  using the 'index' target in the top directory of your
ports tree, or 'portsdb -U'; or to sidestep the problem by using pkgdb
-L followed by portupgrade -O ... ; or to use portmaster with the -t
flag.  (All of these take more time than downloading and using the
index from the repository.)  Alternatively,  you could download an
index or build it once, and then modify it with
ports-mgmt/p5-FreeBSD-Portindex.

If you don't want to use cvs(1), then, in addition to the selective
use of portsnap that the others have mentioned, you can use csup(1)
with the -i flag to update single ports or categories, rather than the
whole ports tree; or you can just download individual ports in a
tarball from the Freebsd cvs web interface, for example:

http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/sysutils/cdrtools-devel/cdrtools-devel.tar.gz?tarball=1

and unpack them into your ports tree.  If you corrupt your old tree,
then you can restore it (even in the absence of a local backup) from a
tarball on old release media or in the FreeBSD ftp archive, or by
using csup with a date keyword, or a branchpoint or release tag.

b.