Major version changes using portupgrade?

[Matthew Seaman]

On 04/12/2011 17:16, Matthew Pounsett wrote:
> On 2011/12/04, at 02:29, Sergio Tam wrote:
> 
>>> >> ===>  postgresql-client-9.1.1_1 conflicts with installed package(s):
>>> >>      postgresql-client-8.4.8
>>> >> 
>>> >>      They will not build together.
>>> >>      Please remove them first with pkg_delete(1).  <----------------pay attention here
>>> >> *** Error code 1
>> > 
>> > 
>> > postgresql-client-8.4.8
>> > 
>> > make deinstall

> That's the ports makefiles talking, isn't it?  In order to do that
> deinstall I need to also remove all of the things that depend on
> it... portupgrade is supposed to help me do the in-place upgrade
> without removing everything else first.
> 
> Even if I forced the deinstall without letting the dependencies get
> in the way, wouldn't that break the dependency registration
> (+REQUIRED_BY) for all of those packages in the future?

Yes.  I've been planning a very similar update -- postgresql 9.0 to 9.1
-- and what I've come up with so far is this:

   0) Backup *everything*
   1) Stop postgresql daemon and any services that depend on postgresql
   2) Move the postgresql data directory aside:

        # mv ~pgsql/data ~pgsql/data-9.0.5

   3) Optional.  If you have WITH_PGSQL_VER defined in /etc/make.conf,
      or similar update it at this point.  Or delete it -- ports will
      pick up the new version automatically once you've updated to it.

   4) Now for the updating bit.  I'm going to use portmaster's '-o'
      functionality to swap out the postgresql versions.  (portupgrade
      has very similar functionality if you prefer that.) postgresql
      is trickier than most, because there have to be both -server and
      -client ports to deal with.  I also have postgresql-contrib-9.0.5
      installed, which isn't critical but needs similar treatment.
      Everything depends on the -client port, so we start with that:

        # portmaster -o databases/postgresql91-client \
	      postgresql-client-9.0.5
	# portmaster -o databases/postgresql91-server \
              postgresql-server-9.0.5_1
	# portmaster -o databases/postgresql91-contrib \
	      postgresql-contrib-9.0.5

   5) Now rebuild everything that depends on the new postgresql client
      port.  Use '-x' and '-R' to avoid rebuilding the ports already
      updated

        # portmaster -R -r postgresql-client-9.1.1_1 \
              -x postgresql-server-9.1.1_1 -x postgresql-contrib-9.1.1_1

   6) Re-init the postgresql cluster

        # su - pgsql
        % mkdir ~/data
        % initdb -D ~/data -E utf8 --locale C
             (or use the rc.d script)
	% vi ~/data/postgresql.conf    (etc...)

   7) Restart the postgresql database

        # /usr/local/etc/rc.d/postgresql start

   8) Reload databases from backup.  Restart all dependent services.

   9) ???

  10) Profit!

This does require an appreciable period of system downtime, but as
that's fine for my purposes, I haven't put any effort into thinking
about how to minimize that.  A good thing to do if downtime is a big
deal for you would be to build updated packages of everything postgresql
related off-line and use portmaster's '-P' package mode to install them.
 Similarly, make backup packages of everything you're updating
(pkg_create -b pkgname) so if you need to back everything out you can
just swap those packages back in rather than doing a full-scale recovery
from backup.

Using this method for a very big database is not amazingly practical --
in that case, using pg_upgrade(8) would probably be preferable, but
that's not going to entirely simple given the constraints of the ports
system.  You'll need to have both the previous and target versions of
the postgresql-client and postgresql-contrib installed simultaneously,
but those ports all conflict with each other.  You'll also need to have
two separate data directories -- the original one and one for the new
version.  The default layout on Linux nowadays includes the postgresql
major version in the data directory path and in the names of most
conflicting applications, but this capability hasn't come to the ports yet.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20111204/e9495d67/signature.pgp