libtool upgrade, entry 20060223 in UPDATING

[Hans Lambermont]

Hi,

The 20060223 entry in UPDATING suggests that the only reliable way of
upgrading a system is to remove all packages and reinstalling from
scratch.

This implies a short week of recompiling (where most of the time is lost
waiting for config input :-/ ), and as I have a staging server available
I'd like to use it for rebuilding all my ports.

The staging server is an exact copy of the production server (dump to
restore pipe over ssh of all partitions). On the staging server I removed
all installed ports first with pkg_delete -f `ls -1 /var/db/pkg`. This
generates a lot of complaints, including "cannot create /dev/null:
Operation not supported". Weird.

Next I rebuild all ports on the staging server (in 1 week) and made
packages of all 400 ports with ls -1 /var/db/pkg|grep -v pkgdb.db|xargs
-n 1 pkg_create -b (there must be a better way, anyone ?).
During this pipe pkg_create generates complaints like:

    tar: share/templates/.keep_me: Could not stat: No such file or directory
    pkg_create: make_dist: tar command failed with code 256

    tar: lib/ao/plugins-2/libesd.a: Could not stat: No such file or directory
    pkg_create: make_dist: tar command failed with code 256

    tar: lib/mozilla/defaults/isp/US/movemail.rdf: Could not stat: No such file or directory
    tar: lib/mozilla/defaults/isp/movemail.rdf: Could not stat: No such file or directory
    pkg_create: make_dist: tar command failed with code 256

Scary.

I now face the upgrade of the production server. First I pkg_delete all
ports, then I need to install the packages built on the staging server.

I'm wondering how to accomplish this as pkg_add *.tgz refuses to
proceed, complaining "pkg_add: too many packages (max 200)". I have over
400. If I choose a smaller subset with for instance pkg_add [a-f]*.tgz I
get dependency problems, +REQUIRED files that are not there yet etc.
How should I proceed ?

Next to that I'd like to hear from others how to accomplish this
all-ports upgrade on servers where one wants the downtime to be minimal.

-- Hans Lambermont