Thread: RPM vs. tar for 6.5.3

I have just finished installing the 6.5.3 tar on my linux database server.
After testing, I have found PostgreSQL to be an excellent database. I was
especially impressed by the full feature set that is available. My thanks to
everyone who has contributed to this project.

I now want to deploy the client to a few workstations, and install the
server on another linux server. What is the best way to deploy this version?
The last time I tried the 6.5.2 RPM's, there where a few things missing, so
I removed them and installed the tar. Are the 6.5.3 RPM's complete? Do I
give up anything by using the RPM's? Is it advisable to install another
server with the RPM's, or is administration hampered if I do this as opposed
to building from the source?

Thanks for your help.

On Mon, 15 Nov 1999, Bruce Bantos wrote:

BB> I now want to deploy the client to a few workstations, and install
BB> the server on another linux server. What is the best way to deploy
BB> this version? The last time I tried the 6.5.2 RPM's, there where a
BB> few things missing, so I removed them and installed the tar. Are
BB> the 6.5.3 RPM's complete? Do I give up anything by using the
BB> RPM's? Is it advisable to install another server with the RPM's,
BB> or is administration hampered if I do this as opposed to building
BB> from the source?

The only way is to install the RPM and find out. ;-)  You may want to
install via tarball for security reasons and control reasons, but I've
found that if you're going to stick with the filesystem layout for a
particular distribution of Linux, the easiest way to do it is to install
the packages built for it.  Another reason to install the tarball over an
RPM may be concurrency with the most recent version.  By their nature,
packages always lag behind the source tarballs and patches.

It's up to you, really.  What I see as a trend for system administrator's
policies is the eventual migration to "roll-your-own" binaries.  For ease
of use and installation, immediate gratification, etc., go with RPM.  For
configurability of the binary, control of the file-placement schema, and
security of the source code, "rolling-your-own" is most definitely the way
to go.

Chad

hi...

> It's up to you, really.  What I see as a trend for system administrator's
> policies is the eventual migration to "roll-your-own" binaries.  For ease
> of use and installation, immediate gratification, etc., go with RPM.  For
> configurability of the binary, control of the file-placement schema, and
> security of the source code, "rolling-your-own" is most definitely the way
> to go.

of course, you can make your own RPMs. there are some decent tools out there to
ease this process. so you can roll you own on one system, package it, and
distribute it as RPM across your network...

--
Aaron J. Seigo
Sys Admin