Re: [ANNOUNCE] i386 RPMs available for v6.5.1

From: Rich Shepard <rshepard(at)appl-ecosys(dot)com>
To: hackers(at)postgresql(dot)org
Subject: Re: [ANNOUNCE] i386 RPMs available for v6.5.1
Date: 1999-07-27 17:06:55
Message-ID: Pine.LNX.4.10.9907270947380.22852-100000@salmo.appl-ecosys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 27 Jul 1999, Thomas Lockhart wrote:

> (back on list, since this is a topic of general RH interest imho)

Makes sense to me.

> RPMs install files into /usr/{bin,lib} and /var/lib/pgsql because
> these same (or similar) RPMs are shipped by RedHat as part of their
> distribution.

I have /usr/bin/postgres and /usr/local/pgsql/doc/* with user postgres
based in /home/postgres. And, of course, /etc/rc.d/init.d/posgresql. If I
understand your message, the only difference I will see by removing all this
and replacing it with the 6.5.1 rpm is that postgres' home directory and the
docs will be in /var and the binary will be in /var/lib rather than
/usr/bin. Is this correct?

> RH feels constrained to *only* install binaries, libraries, etc, into the
> "standard places" which leaves no room for alternatives. As you may know,
> file system layout has been a hot topic for Linux standardization, and
> there isn't much point in trying to fight it, or trying to push RH away
> from their choices ;)

I certainly did not mean to imply that I'm against the nacent standard for
linux file systems! :-) I think that's a Real Good Thing. But, I didn't use
the rpm for 6.4.2 because I couldn't get alternative directories to work ...

> I *believe* that the v6.5.x RPMs will allow you to define your data
> directories, but I agree that it isn't clear how to do this. fyi, the
> way to do this is to use initdb with PGDATA pointed at your desired
> target directory. You might try using "initlocation" to prepare that
> target directory, or you can do this manually.

... despite having done all this. I defined PGDATA2 in ~/.bash_profile as
/home/rshepard/data/accounting. I then ran (as root) initlocation. When I
tried to use pgsql to open a file there, I received error messages that the
directory (or the ../base directory) didn't exist. When I use the source
installation, it works.

> You would also modify /etc/rc.d/init.d/postgresql.init to point to the
> right place.

I have a /etc/rc.d/init.d/posgresql script (no .init). I see references in
there to the postmaster at /usr/bin and a series of references to files in
/var/lib. So, I assume that I need only change the /usr/bin paths to
/var/lib paths to make the upgrade work. Correct?

> pretty fixed). If you (or anyone else) would like to do the RPM
> installation for v6.5.1 to upgrade your v6.4.2 system, I'd be happy to
> help walk you through it, and we can capture that info for the next
> round of docs.

This evening, after work and after I replace the (!!&*%(*)#$%# Seagate tape
drive which died on my after only a year.

Thanks, Thomas!

Rich

Dr. Richard B. Shepard, President

Applied Ecosystem Services, Inc.
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard(at)appl-ecosys(dot)com
Making environmentally-responsible mining happen.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 1999-07-27 17:08:56 Re: More on shared objects problem
Previous Message Jan Wieck 1999-07-27 17:05:28 Re: dynloader and PLs [was: plperl intial pass]