Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

> > Well, we certainly don't want to make changes that make things harder or
> > more confusing for non-RPM installs. How are they affected here?
>
> They wouldn't be. Peter E has seemingly done an excellent job in this
> area. I say seemingly because I haven't built an RPM from the 7.1 branch
> yet, but from what he has posted, he seems to understand the issue.
> Many thanks, Peter.

OK, glad that is done.

> > > * Upgrades that don't require an ASCII database dump for migration. This
> > > can either be implemented as a program to do a pg_dump of an arbitrary
> > > version of data, or as a binary migration utility. Currently, I'm
>
> > I really don't see the issue here.
>
> At the risk of being redundant, here goes. As I've explained before,
> the RPM upgrade environment, thanks to our standing with multiple
> distributions as being shipped as a part of the OS, could be run as part
> of a general-purpose OS upgrade. In the environment of the general
> purpose OS upgrade, the RPM's installation scripts cannot fire up a
> backend, nor can it assume one is running or is not running, nor can the
> RPM installation scripts fathom from the run-time environment whether
> they are being run from a command line or from the OS upgrade (except on
> Linux Mandrake, which allows such usage).

OK, maybe doing it in an RPM is the wrong way to go. If an old version
exists, maybe the RPM is only supposed to install the software in a
saved location, and the users must execute a command after the RPM
install that starts the old postmaster, does the dump, puts the new
PostgreSQL server in place, and reloads the database.

> > Well, no compiler? I can't see how we would do that without making
> > other OS installs harder. That is really the core of the issue. We
> > can't be making changes that make things harder for other OS's. Those
> > have to be isolated in the RPM, or in some other middle layer.
>
> And I've done that in the past with the older serialized regression
> tests.
>
> I don't see how executing a shell script instead of executing a make
> command would make it any harder for other OS users. I am not trying to
> make it harder for other OS users. I _am_ trying to make it easier for
> users who are getting funny results from queries to be able to run
> regression tests as a standardized way to see where the problem lies.
> Maybe there is a hardware issue -- regression testing might be the only
> way to have a standard way to pinpoint the problem.

You are basically saying that because you can ship without a compiler
sometimes, we are supposed to change the way our regression tests work.
Let's suppose SCO says they don't ship with a compiler, and wants us to
change our code to accomodate it. Should we? You can be certain we
would not, and in the RPM case, you get the same answer.

If the patch is trivial, we will work around OS limitations, but we do
not redesign code to work around OS limitations. We expect the OS to
get the proper features. That is what we do with NT. Cygwin provides
the needed features.

> > Please give us more information about how the current upgrade is a
> > problem. We don't hear that much from other OS's. How are RPM's
> > specific, and maybe we can get a plan for a solution.
>
> RPM's are expected to 'rpm -U' and you can simply _use_ the new version,
> with little to no preparation. At least that is the theory. And it
> works for most packages.

This is the "Hey, other people can do it, why can't you" issue. We are
looking for suggestions from Linux users in how this can be done.
Perhaps running a separate command after the RPM has been installed is
the only way to go.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026