Jeff Johnson wrote:
On Jan 22, 2009, at 4:40 PM, Les Mikesell wrote:
Agreed, it doesn't work. Nor does any other RPM-managed update where you need to have both old and new packages simultaneously working for a while. The special case for the kernel is about the only place where it even attempts to keep old versions around for an emergency fallback.
Honking about RPM deficiencies on a CentOS Devel list is hot air going no place.
FWIW, there's no package system that provides sufficient facilties to undertake a postgres upgrade reliably during upgrade that I'm aware of. Nor is it "recommended" afaik.
I thought that point was already conceded.
However, there is nothing now that prevents two versions of postgresql from being built with version-dependent directory names (as it almost is): [root@numbat ~]# rpm -qvl postgresql | grep ^d drwxr-xr-x 2 root root 0 Jan 12 2008 /usr/lib/pgsql drwxr-xr-x 2 root root 0 Jan 12 2008 /usr/share/doc/postgresql-8.1.11 drwxr-xr-x 2 root root 0 Jan 12 2008 /usr/share/doc/postgresql-8.1.11/html [root@numbat ~]# Change that to /usr/lib/pgsql-8.1.11, create a bin directory in there and use the alternatives system to choose the default.
The configuration and data directory names need to be changed too.
But supply a pointer to your favorite package manager that _DOES_ attempt postgres database upgrades and I'll be happy to attempt equivalent in RPM.
Personally, I think that database upgrades have almost nothing to do with instaling packages, but I'd rather add whatever is useful than discuss well known RPM deficiencies for another decade.
In-package (or upgrade-time) configuration conversion will always fail for some packages, but I see no reason that users shouldn't be able to run old and new versions of (at least) _some_ packages simultaneously. It would make upgrades easier for sysadmins with just a few systems to maintain - depending on needs they could upgrade a clone and test it and fix and document broken bits without having to start from scratch each time.