Redhat RPMs (Was: Debian experimental packages ofPostgreSQL 7.4beta4)
От | Nigel J. Andrews |
---|---|
Тема | Redhat RPMs (Was: Debian experimental packages ofPostgreSQL 7.4beta4) |
Дата | |
Msg-id | Pine.LNX.4.21.0310102142410.917-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Debian experimental packages of PostgreSQL 7.4beta4 (Oliver Elphick <olly@lfix.co.uk>) |
Ответы |
Re: Redhat RPMs (Was: Debian experimental packages
|
Список | pgsql-general |
On Fri, 10 Oct 2003, Oliver Elphick wrote: > Debian packages of PostgreSQL 7.4beta4 are available in the experimental > section of the Debian archive. One thing I've been thinking/worrying about recently is the upgrade process. Rest assured this isn't rehashing the pg_upgrade debate though. What I'm wondering about is that I'm faced with a production box that is installed with a Redhat system, that's run by someone else and they do things 'by the book'. That is, software comes in RPM form, possibly RPMS form, but no way does it come in any other form since it's obviously not supported in that case. Now, we're coming up to the time when 7.4 is released, should I go to the extent of porting the db from 7.3 I'll be faced with the situation where the production db has to be brought down to do the upgrade which even after testing may fail in the process. Factor into that that I'm sure the people admin-ing the box probably will not do this during a quiet time, i.e. middle of the night, I have a problem...unless the RPMs are relocatable. I've not looked at many RPMs but I must say that the few I have have never been relocatable. Can the postgresql RPMs not be made relocatable? At least in that case I could run the two versions concurrently rather than the admins be forced to shut 7.3 down, uninstall it, install 7.4, start it up and run the upgrade/load scripts before reenabling the application. If it were me I'd just use stow like I do on all my systems if only more software wouldn't assume it knew where it was going to be installed before configure and build, but that's a whole other gripe. -- Nigel J. Andrews
В списке pgsql-general по дате отправления: