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.
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.
The reason the discussion is intertwined with packaging is that if you name the delivered files the same, the old and new can never co-exist as they should for the conversion and test period.
I think the only way it can be done reasonably is to install the new code with different names and/or paths and scripts that can be run later to do the conversion and (after testing) replacement of the old version.