I've been trying to work out a way to safely upgrade a binary-only
install of the PostgreSQL package in such a way that the old version is
renamed and can remain installed so that the user (i.e. the site DBA)
can subsequently dump the old databases and reload them before the old
package is deleted.

Note that this also has to work for a site using only binary packages,
where the quandry is that you may not know until after you've done the
install that you'll have to dump the old data using the old programs,
but in order to do the install you first have to delete the old
programs.  In the case of something like PostgreSQL deleting the old
package before installing a new one is not possible, especially for a
site that needs to do some regression testing before switching the live
DB to the new version.  (There's nothing too terribly complex about
this, at least not for PostgreSQL -- it's perfectly feasible to do on a
single host, if only the pkg_* tools would permit it.)

I hacked a bit on pkgsrc/mk/bsd.pkg/mk to add a NO_CONFLICTS flag that
prevents a package from conflicting with earlier versions of itself, and
then I did some magic in the PostgreSQL package's INSTALL script to
"move" the already installed package to a unique name (and then it calls
"pkg_admin rebuild" to clean up the newly introduced inconsistencies
with pkgdb.byfile.db).  Ideally packages like PostgreSQL would install
themselves with a pathname prefix that includes their current version
number, just as tcl/tk....  (And indeed I've not tested to see if the
old version is still functional after the move, but that's a different
issue!)

[[ This kind of "upgrade" procedure probably doesn't make sense for
every kind of package -- only those that install themselves entirely
within one or two easily changed directories, i.e. where these prefix
names can be made "unique" (include the release number, for example). ]]

I have this working almost perfectly now for cases where I install the
package from pkgsrc (and when a fairly recent and predictable version is
alreay installed on the system).  Unfortunately pkg_add is one step
ahead of me and has no equivalent to my NO_CONFLICTS flag and it totally
refuses to install the new binary package, even if I try to slurp it up
from stdin.

I was going to continue and hack on pgk_add, but that would require a
custom pkgtools/pkg_install package and I've already spent more than
enough time getting this far so for now I think I'm just going to have
use a slightly different package basename so that I can fool pkg_add,
but this kind of hackery clearly isn't acceptable in the long term.

In any case I think it's absolutely imperative that the pkg_* tools be
"fixed" so that they can at least optionally support simultaneous
installs of different releases of packages (so long as the packages use
unique pathnames for all of their components, of course, but those
checks also already exist).

Discussion?

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>