From: lamar.owen@wgcr.org
Sender: lowen@wgcr.org
Message-ID: <37AFA482.FB66170F@wgcr.org>
Date: Tue, 10 Aug 1999 00:03:14 -0400
Organization: Little to None
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: RPMs (was Pronunciation of "PostgreSQL")
References: <Pine.LNX.4.10.9908091512311.1140-100000@saxony.pathwaynet.com>
	<37AF8B62.58438CD7@alumni.caltech.edu> <37AF9A53.8CC2CE6E@wgcr.org>
	<37AF9D06.A5896F93@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:
> That's building the client into the distro-specific directories for
> perl? Great...

Actually, no -- it's doing exactly what your first run of it did -- and
it works. a simple connect-slect-fetchrows sequence did exactly as
expected -- and fancier constructs worked.  My take on that is to say
that, if it works, use it -- it is being put ina reasonable place with
your install, and perl is happy.  I've done some fairly extensive tests
of that interface, and have yet to crash it.

> > some strange requirements -- ie, the resulting regress.so in the package
> > is built to require /usr/local/bin/perl, and /usr/local/bin/python.....
> > Oh well; I'll slog through it.
> 
> Keep on patching. It's pretty convenient for stuff like this...

Well, I found that it wasn't the regression tests _per se_ that was
causing a failed requires for /usr/local/bin/[perl,python], but some
miscellaneous testing scripts in the test tree -- for reasons of
completness, I'm packaging the whole test tree -- not just the
regression tests, but the performance tests, benchmarks, et al.  On a
RedHat system, perl is always at /usr/bin/perl, and python is always at
/usr/bin/python, but it's easy enough to issue a which perl or which
python to make sure, and to make the RPM as portable as RPM's can get.

> I was just rebuilding the plain RPMs to include the .a forms of the
> libraries, and noticed problems with:
> 
> 1) naming the programming language shared libraries (not libpltcl.so
> but pltcl.so, etc)

Got those.

> 2) finding bin/pgaccess/README.pga (it is obsolete)
> 2a) bin/pgaccess/README should be included in the pgaccess docs target

That's one I haven't yet corrected... Although I have included 0.97b of
the pgaccess tcl script, as /usr/bin/pgaccess97, for testing.

> Here is the spec file for you to compare to previous versions; perhaps
> you can forward your spec file so I don't have to download an entire
> -src.rpm to start scoping it out?

http://www.ramifordistat.net/postgres/postgresql-6.5.1-2lo.spec is the
one I last released.  3lo is not ready for prime-time -- however, I've
uploaded it to postgresql-6.5.1-3lo.spec.beta in the same directory,
rather than take up list bandwidth.

Lamar