Lamar Owen <lamar.owen@wgcr.org> writes:
> 'Brain-dead' meaning WRT upgrading RPMs...:
> 1.) I can't start a backend to dump data if the RPM is installing under
> anaconda;
You can try, but I don't see it as a good idea.
> 2.) I can't check to see if a backend is running (as an RPM pre or post
> script can't use ps or cat /proc reliably (according to Jeff Johnson) if
> that pre or post script is running under anaconda);
This should work, I think.
> 3.) I can't even check to see if the RPM is installing under anaconda!
That should be irrelavant, actually - RPM is designed to be
non-interactive. The best place to do this would probably be in the
condrestart, which is usually run when upgrading and restarts the
server if it is already running.
> (ie, to have a more interactive upgrade if the RPM -U is from the
> command line, a check for the dump, or a confirmation from the user that
> he/she knows what they're getting ready to do)
rpm is non-interactive by design.
> 4.) I'm not guaranteed of package upgrade order with split packages;
Prereq versions of the other components.
> 5.) I'm not even guaranteed to have basic system commands available,
> unless I Prereq: them in the RPM (which is the fix for that);
Yup.
> 6.) The installation chroot system is flakey (again, according to Jeff
> Johnson) -- the least things you do, the better.
No. Yes.
> 7.) The requirements and script orders are not as well documented as one
> might want.
More documentation is being worked on.
>
> Upgrades should just be this simple:
> Install new version.
> Start new version's postmaster, which issues a 'pg_upgrade' in safest
> mode.
> If pg_upgrade fails for any reason, get DBA intervention, otherwise,
> just start the postmaster already!
I would love that.
--
Trond Eivind Glomsrød
Red Hat, Inc.
