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

> Ok, here goes:

Cool, a list.

> * 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.

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?

> * 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.

I really don't see the issue here. We can compress ASCII dump files, so
the space need should not be too bad. Can't you just check to see if
there is enough space, and error out if there is not? If the 2GIG limit
is a problem, can't the split utility drop the files in <2gig chunks
that can be pasted together in a pipe on reload?

> * 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.

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.

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

Well, if we are not specific, things get very confusing for those other
OS's. Being specific about locations makes things easier. Seems we may
need to patch RPM installs to fix that. Certainly a pain, but I see no
other options.

>
> 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.

Oh, that is good.

>
> 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.

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.

--
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