7.1-1 RPMset uploading... - Mailing list pgsql-hackers

From Lamar Owen
Subject 7.1-1 RPMset uploading...
Date
Msg-id 01041323272303.09552@localhost.localdomain
Whole thread Raw
List pgsql-hackers
Ok, the 7.1-1 RPMset for Red Hat 6.2 has been uploaded.  The Source RPM is up,
in RPM 3 format.  Red Hat 7.0 RPMs are on their way. (whew).  28.8K is slow
when uploading 8MB worth of binary RPMset -- as it was when downloading the
source RPM from my 6.2 build machine, located at work and hung off a T1, to my
7.0 home machine.

If you have any queasiness about installing binary RPM's -- then rebuild from
the source RPM.  You will need to review the new REBUILDING FROM SOURCE RPM
section in README.rpm-dist, packaged in the src.rpm (as well as in the main
binary RPM), then review the instructions and tags in the spec file.  You are
able to build the package with pieces not built -- things such as the tcl, tk,
perl, odbcm python, and jdbc clients, as well as the test package, are
optional.  The main, libs, server, docs, ans contrib subpackages are not
optional at this time.

When 7.1 is officially announced, I'll put together an 'official' RPM
announcement (unless you want to mention that as part of the main announcement,
Marc) that I'll post on the various places as well.

Regression passes with this RPMset on both RH 6.2 and RH 7.0 with no special
options or environment variable (or locale sysconfig file) funniness.

If you find obvious errors, please let me know so I can prep a '-2' set quickly
-- however, it will need to be brought to my attention by tomorrow night, or on
Monday, as I do not plan on doing any RPM work on Easter.  Nor do I really plan
on doing any RPM work tomorrow night -- but I will if need be.

No hardcopy docs are included, and the contrib package is One Big Package at
the moment.

Please try various combinations of installations, as the dependencies in this
set are new.

NOTE TO LINUX DISTRIBUTION PEOPLE ON THIS LIST:
I am in process of changing the focus of the PostgreSQL.org RPMset from a
do-all-end-all-be-all RPM to a 'template' RPMset, that will work for most
everyone but is meant as a foundation from which to build your
distribution-specific RPMset for PostgreSQL.  I would request that your
distribution-specifc RPMset be flagged as such if it deviates from what is in
this RPMset -- change the release number to associate it with your distro, such
as the 'mdk' added to all Mandrake RPMs flag those RPM's as belonging to
Mandrake.  The source RPM should build as-is on any distribution that is
reasonably close to LSB compliant and uses an RPM of at least version 3.0.4 --
3.0.5 or greater is very much preferred.  I will try to refrain from using RPM
4 specific features until my list of supported distributions no longer includes
Red Hat 6.2, which has RPM 3.0.5 as its errata update release -- but you will
NEED RPM 3.0.5 to rebuild, more than likely.

I would also like to receive any patches to any files in the RPM that you
modify in any way -- if those changes would be useful to the generic RPMset.

Please read the README.rpm-dist file packaged in both the source RPM and the
main package.  For your convenience, that file is attached to this message.

A minimal PostgreSQL server installation will need the main package, the libs
subpackage, and the server subpackage to function.  Client only installations
may pick and choose -- eg, if you use the Python client exclusively, then you
only need the libs and python subpackages. 

BIG NOTE:
Before upgrading your previous PostgreSQL installation, be sure you understand
how the upgrade process works.  Make absolutely SURE that you have the previous
version's RPMset to reinstall if you need to do so, and take a full ASCII
pg_dumpall (or your preferred backup method, such as iterative pg_dumps as
discussed on this list).  The semi-automatic process, when it works, works
well.  It has been known to not work, as it is attempting to do a very hard
thing.  BE SURE YOU HAVE A KNOWN GOOD BACKUP.  PLEASE -- for the sake of YOUR
data.  If you need large objects migrated, you need to compile the contributed
pg_dumplo utility yourself for 7.0.x and dump those large objects FIRST.

There are instances of data dumped with 7.0 not restoring properly with 7.1 (as
documented on this list) -- have a copy of you BINARY tree stored offline so
that you can go back to your previous version if the need arises.

Otherwise, enjoy the RPMset :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Possible explanation for readline configuration problems
Next
From: Tom Lane
Date:
Subject: Re: Possible explanation for readline configuration problems