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

Bruce Momjian wrote:
>
> > However, the upgrade gotcha has left a very bitter taste in more than
> > one user's mouth. I'll not say more about that now, as I've said quite
> > enough in the past. And I'm still trying to figure out enough of the
> > internals of the storage manager to try to write the migration tools
> > myself. But, I have other fish to fry right now, the biggest being
> > cross-distribution RPM's.
>
> Actually, I would prefer to see how we can improve what we have before
> making a binary conversion utility that will have to be updated for
> every release.
>
> > Meet Mr. Middle Layer. :-) The PostgreSQL spec file that controls the
> > RPM build is one of the most complex ones in the RedHat distribution,
> > AFAIK. There's the middle layer. It does quite a bit of finagling
> > already.
>
> Yes, I suspected the RPM was the middle layer. To the extent we can
> make that easier, let's hear it. Tell us what you need to do, and what
> you can't do, and see if any of us can figure out how to make things
> easier.

Ok, here goes:
* Location-agnostic installation. Documentation (which I'll be happy to
contribute) on that. Peter E is already working in this area. Getting
the installation that 'make install' spits out massaged into an FHS
compliant setup is the majority of the RPM's spec file.

* 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
saving old executables to run under a special environment to pull a dump
-- but it is far from optimal. What if the OS upgrade behind 99% of the
upgrades makes it where those old executables can't run due to binary
incompatibility (say I'm going from RedHat 3.0.3 to RedHat 7 -- 3.0.3,
IIRC, as a.out...( and I know 3.0.3 didn't have PostgreSQL RPMs).)?
What I could actually do to prevent that problem is build all of
PostgreSQL's 6.1.x, 6.2.x, 6.3.x, 6.4.x, and 6.5.x and include the
necessary backend executables as part of the RPM.... But I think you see
the problem there. However, that would in my mind be better than the
current situation, albeit taking up a lot of space.

* A less source-centric mindset. Let's see, how to explain? The
regression tests are a good example. You need make. You need the source
installed, configured, and built in the usual location. You need
portions of contrib. RPM's need to be installable on compiler-crippled
servers for security. While the demand for regression testing on such a
box may not be there, it certainly does give the user something to use
to get standard output for bug reports. As a point, I run PostgreSQL in
production on a compilerless machine. No compiler == more security.
And Linux has enough security problems without a compiler being
available :-(. Oh, and I have no make on that machine either.

The documentation as well as many of the examples assume too much, IMHO,
about the install location and the install methodology.

I think I may have a solution for the library versioning problem.
Rather than symlink libpq.so->libpq.so.2->libpq.so.2.x, I'll copy
libpq.so.2.1 to libpq.so.2 and symlink libpq.so to that. A little more
code for me. There is no real danger in version confusion with RPM's
versioning and upgrade methodology, as long as you consistently use the
RPMset. The PostgreSQL version number is readily found from an RPM
database query, making the so version immaterial.

The upgrade issue is the hot trigger for me at this time. It is and has
been a major drain on my time and effort, as well as Trond's and others,
to get the RPM upgrade working even remotely smoothly. And I am willing
to code -- once I know how to go about doing it in the backend.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11