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

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Rich Shepard <rshepard(at)appl-ecosys(dot)com>, Postgres Hackers List <hackers(at)postgresql(dot)org>
Subject: Re: [ANNOUNCE] i386 RPMs available for v6.5.1
Date: 1999-07-27 16:12:05
Message-ID: 379DDA55.D5F9FEB0@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> > I've posted RPMs for v6.5.1 at
> I'm curious why the rpm installs place postgres files in different
> directories than does the .tgz source files. When I installed 6.4.2, I had
> all sorts of problems with the rpm version because it wouldn't let me define
> and use my own data directories (e.g., ~/data/accounting). I finally figured
> out how to configure, make and install the source according to the
> Administrator's Guide.

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. 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 ;)

It would be possible to build RPMs which install into the areas
documented directly in Postgres, but imho that is not helping by much,
since on different (non-Linux) systems the best locations will, in
general, vary, and RH is just an example of that.

Now that we can generate our own RPMs, we can do a better job of
documenting the RPM behavior. Before, that was a RH black box.

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. For the RH
installation, set the protections and ownership the same as for
/var/lib/pgsql; your postgres account needs to own the directory and
the protections should be 700.

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

> Now I'm ready to do some serious porting of my DOS-based business
> applicaitons. I'm going to use GTK+ for the GUI, C for the glue and I think
> that I ought to upgrade to 6.5.1 from the present 6.4.2. But, I hesitate.
> Postgres appears to function now and I don't want to spend more time
> floundering around trying to get 6.5.1 up and running instead.
> So, my question: should I grab the 6.5.1 .tgz file and follow the steps I
> used for the 6.4.2 installation rather than using the package?

imho, the RPMs are most appropriate for casual users or small
installations, but I think that they could be used successfully in a
large installation too. Especially as you deploy production servers,
the flexibility you get by a from-source installation is not as
important, and the convenience of an easy installation process is more
important. A from-source installation gives you the most control over
(server) installation issues, and more importantly would let you more
easily apply workaround patches during the lifetime of that version.
I'd suggest using a from-source when doing development, and the RPMs
when deploying, but that is just me...

The RPMs seem to me to be entirely appropriate for any and all
client-only installations, for both small and large configurations.

With a bit more docs, the RPM installation can be (almost) as flexible
as a from-source installation (but the target locations are afaik
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.

Regards.

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 1999-07-27 16:52:55 Re: [CORE] Re: [Keystone Slip # 22] Some confusion with datetimedata type andtimezone
Previous Message Oleg Bartunov 1999-07-27 15:46:38 Re: [HACKERS] UPDATE performance degradation (6.5.1)