Re: Compiling to RPM setup/filesystem layout

> I'm patiently waiting for the 7.1.2 RPMs to be released. Since there's
no
> indication when they may be ready, I'd like to try compiling PostgreSQL
> myself.
>
> Unfortunately, I can't just "compile" since I need to be able to replace
my
> current 7.0.3 installation, installed via RPMs. How do I go about this
so I
> don't mess everything up (leftover files and such, in addition to the
> mandatory pg_dump) ? Also, how do I ensure that when future RPMs come
out,
> I can just use the RPMs and upgrade a compiled version?

On going from RPM to source:
---------------------------------
The easiest way to upgrade is to do your pg_dumpall to get your data
out (having a few backups of it isn't a bad idea), then un-install the RPM
for Postgres. Myself, I prefer to remove all of RedHat's RPM's related to
Postgres, but that's up to you to decide.

Once the RPM's are uninstalled, install from the source following the
instructions. Try it once or twice on a practice machine once or twice,
and you'll feel a lot more comfortable.

On future compatibility with RPM's>
-----------------------------

If you want to ensure compatibility with future versions of RPM's,
you'll have to fiddle around with several options to the autoconf, but
myself, I really recommend against it, and here's why:

If you install from source, it will default to /usr/local, which is
(IMHO) a good place for it to be, and it will put it's libraries and
binaries under the destination directory (usually /usr/local/pgsql).
IMHO, that's a very good thing, as it makes administration and upgrades
terribly easy. If you want the data under /var (as it does vary), you can
certainly do that as well, and quite easily. Myself, I just have a large
partition that gets mounted as /usr/local/pgsql/data . That way, if
something else fills up /var, PG isn't hosed. And if PG fills up it's
partition, other services aren't hosed.

Now, play some villanous music, and enter RedHat wearing a black cape,
with small, beedy eyes. They insist that an OS should not touch
/usr/local, and they're right about that. However, if you choose to
download the Postgres RPM and install it via RPM yourself, they seem to
interpret that as "the OS touching /usr/local", and it won't happen. You
will end up with the binaries in /bin or /usr/bin, the libraries in /lib
or /usr/lib, and the postgres data directory under /var, if I recall. In
short, it spreads things out quite a bit, making it a headache to track
things down.

So, the problem at that point is that if you mix installations from
source and RPM, you have conflicts with multiple library and binary
versions, with your path determining which one actually gets called. Very
ugly. So, either stick with RPM's, and get RedHat's ideas about where
libraries and binaries should go (and the accompanying mess), or stick to
the source, and get them where the developpers meant them to go, but don't
mix them.

steve