[Gllug] RH rpm upgrading

[James de Lurker]

Wed, 04 Jun 2003 18:07:34 +0100  Martin A. Brooks wrote:
> At 16:36 04/06/2003 +0100, you wrote:

>> Rubbish. RPM can do all of that with various combinations of %doc, 
>> %ghost,
>> and pre- and post-install scripts.

Often impractical where a user might "jump" any number of intermediate
release stages in the upgrade of an application. It is too expensive to
consider and program for every eventuality in the spec file.

In the specific case of postgresql, maintaining via rpm can be fraught
for the unwary. There are comparable complexities for other applications
maintained via rpm, too. Always use THEIR tools to backup and preserve
settings before resorting to a "black box" systems approach and expecting
rpm -Uv to do everything for you. It could (and probably will) end in tears!

For postgresql *always* make sure that you have backed-up the database
beforehand, using the postgresql tools. Backup other user definitions,
working directories, etc by usual means. Then uninstall and re-install
again as rpm -ivh. Restore the database ONLY USING posgresql tools! restore
other working directories / database user stuff manually. ALways keep
copies of the defaults before overwriting anything, so you can roll back
without pain.

Generally rpm -Uv is workable for point releases. But I don't recommend it.


An rpm "play safe" feature is that an rpm upgrade rpm -U finding previous 
config files will install the new config files as *.rpmnew

For a security patch this can be dangerous. In one I noticed, there were
new constants defined in the updated config file; running the system would
have left those constants in the default state with the new binaries: OFF.
Always keep reference copies of your config files ( *.conf.nnn )

diff -ay whatever.conf.rpmnew  conf.nnn  is a neat way of quickly
identifying the changes to chase up.

locate rpmnew  is something I recommend to everyone with older, otherwise
well maintained RedHat systems ( such as 6.2, 7.x ) How many unresolved
rpmnew issues do _you_ have? Feedback from affected GLLUGers would be
interesting!

For postgresql specifically, my systems use the postgresql SRPMS as
source rather than RedHat's production ones.

7.3.2 is the last available, AFAIK they have not yet released any SRPMS
for 7.3.3 :-(  SRPMS are under here: ftp://ftp.us.postgresql.org/binary/

If you take the time out to read the postgresql documentation, and have
had the experience of "upgrading" regularly from 7.0, you'll quickly
appreciate that there are too many possibilities to program into the
spec file to guarantee success. If you don't need, or have already backed
up the existing database (using the postgre tools provided), it is safest
to uninstall postgresql and then re-install using rpm -ivh


> Great, I always like to be proved wrong - it means I've learned something.

Experienced the pain of FUBAR several times using rpm -Uv, blithely 
trusting the spec file to sort everything out automagically. That makes the 
lesson a memorable one.


> Could you please point me at the RPM that will migrate postgres 7.0 to 
> postgres 7.3 rebuilding any databases appropriately. I'd be very 
> interested in testing it.

You can't just rpm -Uv or -Fv here.

Sorry to say RTFM for the application's own readme files and other
documentation, but there is truly no other safe option... Don't take the
MFI approach, and read this stuff AFTER doing a package "upgrade" and
losing new components, or breaking old ones.

You'll have "But first..." ringing in your ears for a long time!

-- 

   -- James

 From and Reply To are INVALID.

All public postings use munged headers[1]- To contact me off list:
   1) Remove "M U N G I E j u m p" ONLY: leave that "nospam" in there!
   2) change "hotmail" 2 "myrealbox" after the @



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug