Thread: 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?
Gerald Gutierrez <gml1@coldresist.com> writes: > I'm patiently waiting for the 7.1.2 RPMs to be released. You can find source rpms at http://people.redhat.com/teg/pg/ -- Trond Eivind Glomsrød Red Hat, Inc.
> 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
Gerald Gutierrez <gml1@coldresist.com> writes: > 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? Here's my advice: 1) Compile 7.1.2, and do "make install". This will put the binaries, libs, manpages etc in /usr/local/pgsql, which doesn't conflict with the RPMs at all. 2) Do pg_dumpall on your 7.0.3 database (after making sure all users are disconnected). Shut down the database. 3) Rename your current PG data directory, rather than blowing it away (so you can easily go back to 7.0.3 if you have trouble). This assumes, of course, that disk space is plentiful. 4) Make a new PG data directory, set ownership and mode to postgres:postgres:700. 5) Log in as 'postgres' and set the following environment variables: export PATH=/usr/local/pgsql/bin:$PATH export PGDATA=<wherever your PGDATA lives> export LD_LIBRARY_PATH=/usr/local/pgsql/lib 6) You should then be able to do 'initdb $PGDATA' and initialize the database. 7) Run 'pg_ctl start' to fire up the new postmaster. 8) Do 'psql -f <dumpfile> template1' to load the old data. 9) You'll have to either modify /etc/rc.d/init.d/postgresql to start the new binary, or disable it and roll your own. Client applications need to have LD_LIBRARY_PATH (and possibly PATH as well) set so they look in the right place for stuff; otherwise they will pick up old libs as long as the RPMs are still installed. Once this is working, you can remove the RPMs if you want, or just leave them around until you're ready to do an RPM upgrade. Upgrading to 7.1.2 RPMs *should* be relatively straightforward, and not require an initdb, unless you've done something weird when configuring the source. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan
Gerald Gutierrez writes: > 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) ? Install the "compiled" version somewhere else and run them in parallel. Once you're finished doing the data conversion, remove the RPM version. > Also, how do I ensure that when future RPMs come out, > I can just use the RPMs and upgrade a compiled version? That probably won't work the way you imagine it. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
"Steve Wolfe" <steve@iboats.com> writes: > Now, play some villanous music, and enter RedHat wearing a black cape, > with small, beedy eyes. I don't have a cape, but I do have a red hat. And blue eyes, normal size. > 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. For managed distributions, the standard way of doing things is "if it's in the package format, put it in /usr. /usr/local is for things not managed by this system (rpm, deb, whatever)" (typically this means things installed by loki :), things compiled locally without package systems (configure && make install) etc. > 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. You'll end up with the binaries in /usr/bin, the libraries in /usr/lib and the data in /var/lib/pgsql. Like it should be :) > 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) No mess, sanity is included. > or stick to the source, and get them where the developpers meant > them to go, but don't mix them. "mean them to go" - that this is the default location doesn't mean they are meant to go there. The default values of autoconf point at where it would go if it was locally compiled and installed. A distribution is another scenario - you wouldn't claim that e.g. bash should be in /usr/local/bin because that's the default autoconf location, would you? -- Trond Eivind Glomsrød Red Hat, Inc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 31 May 2001 15:59, Gerald Gutierrez wrote: > 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. Oooo... Saturday afternoon. I'm making a few changes to the build that I need to test before releasing, so expect a release Saturday. > 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? If you want to go to a from source distribution, do the following: pg_dumpall your whole database to somewhere other than /var/lib/pgsql. rpm -qa|grep ^postgresql rpm -e all-of-the-postgresql-rpms-you-found rm -rf /var/lib/pgsql Install from source into /usr/local/pgsql just like you want to. If you have other RPM's that depend upon the PostgreSQL RPM's provides, then you have a bigger problem. The easiest way to deal with that is waiting until Saturday and downloading the new version. But even then you need to do a full dump of your data! - -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Fqj+5kGGI8vV9eERAmzRAKCfgPeJozqOc+nDLy4Ke91lo3IF2ACdHok+ fFTF2YHhSmNQ7wpUWr7LEZs= =ufSj -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 31 May 2001 16:22, Steve Wolfe wrote: > something else fills up /var, PG isn't hosed. And if PG fills up it's > partition, other services aren't hosed. Make a partition mounted on /var/lib/pgsql. :-) > 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 Linux Standards Base and the Filesystem Hierarchy Standard sets that policy, not Red Hat. And I happen to think it installs to the right place, IMHO. :-) And Red Hat ain't no villain -- unless you're a BSD partisan who thinks Red Hat is responsible for popularizing Linux beyond its worth (that, incidentally, is a friendly dig at scrappy.....) If you like Linux, you should absolutely adore Red Hat -- if nothing else, for payrolling Alan Cox and the stable kernels. > 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. Running rpm -ql on the RPMset is too much of a hassle, right? Removing all traces of the RPMset is easier than removing all traces of a from-source install. > 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. Developing a great RDBMS != knowing where to put that RDBMS in the systems context. Sorry. Although, as I _am_ mentioned as a 'Developer' on the globe, and the RPM puts the files where I mean for them to go... well, you decide the worth of that. And followup to the PORTS list, as this is a ports, not a general, issue. - -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7FrHx5kGGI8vV9eERAqQuAKDqga82vmuJukgprQbvV84wnO+OJgCcCWrr hcuKxQvjny3e4V5m0Ky1hy0= =EhNS -----END PGP SIGNATURE-----
> > Now, play some villanous music, and enter RedHat wearing a black cape, > > with small, beedy eyes. > > I don't have a cape, but I do have a red hat. And blue eyes, normal size. I was going for the melodrama. : ) > > 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. > > For managed distributions, the standard way of doing things is "if > it's in the package format, put it in /usr. /usr/local is for things > not managed by this system (rpm, deb, whatever)" (typically this > means things installed by loki :), things compiled locally without > package systems (configure && make install) etc. "standard" rarely equates to "correct" or even "useful". But I'm going to drop the rest of the message, I had all of my arguments written out, but remembered that this is the Postgres list. The main point of my message was that you should stick to source or RPM, mixing the two isn't that great. I apologize if you took offense at my comments. steve
> > 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) ? > > Install the "compiled" version somewhere else and run them in parallel. > Once you're finished doing the data conversion, remove the RPM version. If you do that, either fully qualify your calls to psql and other utilities, or create aliases for them. Otherwise, the RPM'd versions with binaries in /usr/bin can be called instead of the binaries you really want, and there are circumstances where that will cause problems, even though the developpers have done a wonderful job of making sure that things will work as well as can be expected with mis-matched versions. : ) steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 31 May 2001 16:22, Steve Wolfe wrote: > something else fills up /var, PG isn't hosed. And if PG fills up it's > partition, other services aren't hosed. Make a partition mounted on /var/lib/pgsql. :-) > 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 Linux Standards Base and the Filesystem Hierarchy Standard sets that policy, not Red Hat. And I happen to think it installs to the right place, IMHO. :-) And Red Hat ain't no villain -- unless you're a BSD partisan who thinks Red Hat is responsible for popularizing Linux beyond its worth (that, incidentally, is a friendly dig at scrappy.....) If you like Linux, you should absolutely adore Red Hat -- if nothing else, for payrolling Alan Cox and the stable kernels. > 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. Running rpm -ql on the RPMset is too much of a hassle, right? Removing all traces of the RPMset is easier than removing all traces of a from-source install. > 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. Developing a great RDBMS != knowing where to put that RDBMS in the systems context. Sorry. Although, as I _am_ mentioned as a 'Developer' on the globe, and the RPM puts the files where I mean for them to go... well, you decide the worth of that. And followup to the PORTS list, as this is a ports, not a general, issue. - - -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7FrHx5kGGI8vV9eERAqQuAKDqga82vmuJukgprQbvV84wnO+OJgCcCWrr hcuKxQvjny3e4V5m0Ky1hy0= =EhNS - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7FrWn5kGGI8vV9eERAvIxAJ9Z61FEmUreB7JRfSzjcAZmonRZQACdFzM5 TYy6lPwyYPbK6AJz4WNusko= =aI3d -----END PGP SIGNATURE-----
> On Thursday 31 May 2001 16:22, Steve Wolfe wrote: > > something else fills up /var, PG isn't hosed. And if PG fills up it's > > partition, other services aren't hosed. > > Make a partition mounted on /var/lib/pgsql. :-) Touche! > > 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 > > Linux Standards Base and the Filesystem Hierarchy Standard sets that policy, > not Red Hat. And I happen to think it installs to the right place, IMHO. :-) I'm talking about a user installing software on his own. Does the LFS and FHS still mandate it not go into /usr/local in that case? > And Red Hat ain't no villain -- unless you're a BSD partisan who thinks Red > Hat is responsible for popularizing Linux beyond its worth (that, > incidentally, is a friendly dig at scrappy.....) That was purely for dramatic effect, I didn't mean that they were actually villains. I believe that there are some investors that would argue against you, from what I hear of the lawsuit, but I haven't concerned myself with that enough to know the details. > If you like Linux, you > should absolutely adore Red Hat -- if nothing else, for payrolling Alan Cox > and the stable kernels. I wasn't aware that they did - but for that, I do absolutely applaud them. I do have a few things that concern me about their kernels, but I'll leave that for a relevant forum. > Running rpm -ql on the RPMset is too much of a hassle, right? Removing all > traces of the RPMset is easier than removing all traces of a from-source > install. Really? Let's compare removing the RPM's: #rpm --erase postgresql-devel-6.5.3-6 #rpm --erase postgresql-jdbc-6.5.3-6 #rpm --erase postgresql-odbc-6.5.3-6 #rpm --erase postgresql-perl-6.5.3-6 #rpm --erase postgresql-python-6.5.3-6 #rpm --erase postgresql-server-6.5.3-6 #rpm --erase postgresql-tcl-6.5.3-6 #rpm --erase postgresql-test-6.5.3-6 #rpm --erase php-pgsql-3.0.15-2 #rpm --erase postgresql-perl-6.5.3-6 #rpm --erase postgresql-python-6.5.3-6 #rpm --erase postgresql-server-6.5.3-6 #rpm --erase postgresql-tcl-6.5.3-6 #rpm --erase postgresql To removing the installation from source: rm -rf ~postgres/* I think that the second is much easier, in my opinion. > Although, as I _am_ mentioned as a 'Developer' on the globe, and the RPM puts > the files where I mean for them to go... well, you decide the worth of that. > > And followup to the PORTS list, as this is a ports, not a general, issue. I'm sorry, I don't know how that ended up there. I'll fix it. steve
"Steve Wolfe" <steve@iboats.com> writes: > > Running rpm -ql on the RPMset is too much of a hassle, right? Removing > > all traces of the RPMset is easier than removing all traces of a from-source > > install. > > Really? > > Let's compare removing the RPM's: rpm -e `rpm -qa |grep postgresql` [...] > #rpm --erase php-pgsql-3.0.15-2 That's not what you're doing for your manual install... > rm -rf ~postgres/* So postgres doesn't install it's binaries in /usr/local/bin, libraries in /usr/local/lib etc? -- Trond Eivind Glomsrød Red Hat, Inc.
> > Let's compare removing the RPM's: > > rpm -e `rpm -qa |grep postgresql` Nice. I like it. > > #rpm --erase php-pgsql-3.0.15-2 > > That's not what you're doing for your manual install... > > > rm -rf ~postgres/* > > So postgres doesn't install it's binaries in /usr/local/bin, libraries > in /usr/local/lib etc? I'm not sure what you mean. When it's installed with the autoconf defaults, the binaries go in /usr/local/pgsql/bin, and the libraries are in /usr/local/pgsql/lib (assuming that you've chosen /usr/local/pgsql for the base directory), and removing all traces is as easy as removing that directory, assuming that you've followed the commonly-used practice of having /usr/local/pgsql/data as your "data" directory. (Yes, that should technically go under /var.) Since the binaries aren't in /bin, I generally add /usr/local/pgsql/bin to the path in /etc/profile, and /usr/local/pgsql/lib to /etc/ld.so.conf, as described in the docs, so I suppose that to remove *every* trace, you're right, I'd have to remove those lines as well, even though having them around without an installation of PG isn't going to hurt much. steve
Hi all. Thanks for all the good advice on how to deal with the source and the RPMs. The PostgreSQL RPM "god" has just spoken, so I think I'll be waiting until Saturday to get the new RPMs. But I'll be saving the messages for when the next version of PostgreSQL comes out and I can't wait for the prepackaged binaries. :) Gerald. At 04:26 PM 5/31/2001 -0400, Lamar Owen wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thursday 31 May 2001 15:59, Gerald Gutierrez wrote: > > 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. > >Oooo... Saturday afternoon. I'm making a few changes to the build that I >need to test before releasing, so expect a release Saturday.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 31 May 2001 17:33, Steve Wolfe wrote: > > On Thursday 31 May 2001 16:22, Steve Wolfe wrote: > I'm talking about a user installing software on his own. Does the LFS > and FHS still mandate it not go into /usr/local in that case? But the PostgreSQL RPM's are used as a base for distributors' distributions, which _do_ need to adhere to LSB/FHS. > > traces of the RPMset is easier than removing all traces of a from-source > > install. > Really? > Let's compare removing the RPM's: > To removing the installation from source: > rm -rf ~postgres/* > I think that the second is much easier, in my opinion. Removing the RPM's -- assuming other software isn't install that depends upon postgresql: # /etc/rc.d/init.d/postgresql stop # rpm -qa|grep ^postgresql|xargs rpm -e # rm -rf /var/lib/pgsql and you're done. - From source: Stop postmaster. Remove /usr/local/pgsql/bin from the PATH of everybody who uses postgresql. rm -rf /usr/local/pgsql Edit /etc/ld.so.conf Run ldconfig. Looks longer, IMO. - -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7F/Nt5kGGI8vV9eERAlGLAJ9HJuooAFF1noi79QE4/fePUwnT8wCfVF3y fB3OGAKV3onXutMhDOJD8kQ= =jxte -----END PGP SIGNATURE-----