Re: Compiling to RPM setup/filesystem layout - Mailing list pgsql-general
From | Steve Wolfe |
---|---|
Subject | Re: Compiling to RPM setup/filesystem layout |
Date | |
Msg-id | 003001c0ea0f$7840de20$50824e40@iboats.com Whole thread Raw |
In response to | Compiling to RPM setup/filesystem layout (Gerald Gutierrez <gml1@coldresist.com>) |
Responses |
Re: Compiling to RPM setup/filesystem layout
Re: Compiling to RPM setup/filesystem layout Re: Compiling to RPM setup/filesystem layout |
List | pgsql-general |
> 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
pgsql-general by date: