Re: Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)

On Friday 20 July 2001 18:45, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > On to the next batch....  There are a few perl and python scripts shipped
> > as examples -- every last one of them shebangs to '/usr/local/perl' or
> > '/usr/local/python' -- to make them usable, I patch this to
> > '/usr/bin/perl' or python, as appropriate.

> Hmm.  Given that they're only examples, and are clearly going to be
> broken until hand-edited on many systems not only RedHat, it's not clear

Well, there were more than just a few at one point.  In any case, it's been 
awhile since I combed through the example scripts -- of which I only now ship 
the one, which is designed to test the perl client -- which I find to be a 
useful thing.

> BTW, the only python shebangs I can find in CVS look like
>     #! /usr/bin/env python
> Isn't that OK on RedHat?

Yeah, that construct is OK.  7.0.x was different, unless I'm far off-base.  
But I'm not shipping any patched python scripts with 7.1.x anyway -- the 
6.5.x and 7.0.x dists had some scripts with #!/usr/local/bin/python.

So much for my 'every last one,' eh? :-)

> Much of this could be eliminated given the new path-searching behavior
> for CREATE FUNCTION, I think.  Actually I thought Peter had cleaned it
> up already, but I see he hasn't touched the regression tests.  

How is this search path defined?  Blindly using libdir is not ok -- 
libdir!=PGLIB, and PGLIB may not be defined in the environment -- it might be 
there, but we can't count on it.

> IMHO we
> could have "make installcheck" copy the .so files to $LIBDIR,

libdir!=PGLIB for the RPMs.  libdir=/usr/lib; PGLIB=/usr/lib/pgsql.  I was so 
happy when the bki sources were no longer referenced by PGLIB -- when the 
procedural language handlers aren't thusly referenced will be a Happy Day.  
If PGLIB could = libdir, and something like PGHANDLER= where the handlers 
live, I'd also be happy.  If this function search path can be configured to 
search in /usr/lib/pgsql and all or any of its subs, while libpq and kin live 
in /usr/lib, I _will_ be happy.

> and then
> the regression test input and output files themselves wouldn't need to
> know these paths at all.  (OTOH, there'd still be paths in the COPY
> commands.  Would it be okay to eliminate testing of backend COPY and
> instead make these regression tests use psql \copy?)

The COPY paths are munged into form by the GNUmakefile patch -- so, if the 
GNUmakefile can generally deal with the paths by placing relative paths 
(relative to what, though?) in the @abs_srcdir@/@abs_builddir@ substitutions, 
then those paths aren't an issue.

Although a psql \copy regression test might be a good thing in its own right.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11