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