Date: Sat, 26 Feb 2011 15:48:37 +0000
From: Natanael Copa <ncopa@alpinelinux.org>
To: Ted Trask <ttrask01@yahoo.com>
Cc: Alpine Developers <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Proper way to handle major version upgrade for a
 package
Message-ID: <20110226154837.18a10a68@alpinelinux.org>
In-Reply-To: <759731.20927.qm@web130104.mail.mud.yahoo.com>
References: <759731.20927.qm@web130104.mail.mud.yahoo.com>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, 26 Feb 2011 03:36:07 -0800 (PST)
Ted Trask <ttrask01@yahoo.com> wrote:

> I have a major version bump for acf-weblog in the works.
> Unfortunately, it's not backwards compatible. Since acf-weblog uses
> postgres, it got me thinking about how the upgrade from postgres 8 to
> 9 went. In Alpine Linux 2.1, we released postgresql 9.0. Since the
> data directory moved, a simple 'apk upgrade' from postgres 8 to
> 9=A0broke any=A0existing postgres databases. There was no real warning
> for users. The release notes
> (http://www.alpinelinux.org/wiki/Release_Notes_for_Alpine_2.1.0)
> mentioned the version bump, but nothing about the incompatibility.
> The only way they would be aware of the problem was with insider
> knowledge about postgres. I had several users run into this problem.

The list of app in the mentioned release notes was thought as: This is
the list of apps that is not compatible with current. If you run any of
those you might want check with upstream on how to upgrade.

And for postgresql, they have always required dump/restore for
upgrading (except when you upgrade from x.y.z to x.y.z+1)

>=20
> What is the proper way to handle upgrades like this?
>=20
> 1) Put the upgraded package in a newer version of Alpine Linux (ie
> 2.2) with a note in the release notes? Let the user beware.
> 2) Add upgrade instructions to the Alpine release notes? (like=20
> http://www.alpinelinux.org/w/index.php?title=3DTemplate:UpgradeTo2)
> 3) Try to create pre/post install scripts to make the upgrade
> seemless?

4) ship a package named postgresql8.4 *and* postgresql9.0 which both
can be installed at the same time.

> I know option 3 would be a lot of work, considering the number of
> packages=A0we now have,=A0but it's the 'nice' thing to do. Thoughts?

One of the new things in postgresql-9 was a tool that should make
online upgrades easier iirc. We might want check that out.

But postgresql upgrades have always been tricky. I remember when
upgrading a mediawiki install, it was not as simple as just
dump/restore.

For smaller things I'd recommend using sqlite.

> Ted Trask
>=20
> P.S. Should we go back and try to make the postgres upgrade cleaner
> for future users who upgrade to 2.1?

We could make a pre-upgrade script that checks if postgres is running
and exit with error if it is.

Something like:

# if we upgrade from something older than 9.0...
if [=A0"$(apk version -t $2 9.0)" =3D "<" ]; then
	# check if it is running
	if ! rc-status -q postgresql; then
		exit 0
	fi

	echo "You should do a pg_dump and stop postgres service before
	upgrading and pg_restore afterwards. Please consult the
	postgresql documentation" >&2
	echo "Aborting upgrade" >&2
	exit 1
fi
exit 0

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---