Compiling to RPM setup/filesystem layout

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

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

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

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

make uninstall

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 01 June 2001 11:07, Peter Eisentraut wrote:

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

make uninstall

But that doesn't remove _all_ traces, does it? :-)

My point is that removing and upgrading the RPMset isn't a big pain.
- --
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/y55kGGI8vV9eERAhdgAJ4mFwTtcnZr9rP4BkQKwUGdwJ7r6gCfXVA0
oBbQMfwl/69YN7FVu7t7zZo=
=Wcme
-----END PGP SIGNATURE-----

Lamar Owen writes:

make uninstall

But that doesn't remove _all_ traces, does it? :-)

It would in theory, if it weren't for some nonsense like MakeMaker.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter