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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
Дата
Msg-id 5538.995669113@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)  (Lamar Owen <lamar.owen@wgcr.org>)
Ответы Re: Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)  (teg@redhat.com (Trond Eivind Glomsrød))
Re: Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)  (Lamar Owen <lamar.owen@wgcr.org>)
Список pgsql-hackers
Lamar Owen <lamar.owen@wgcr.org> writes:
> Ok, let's look.  First, there is a createlang issue: during build, @libdir@ 
> as referenced in the createlang script references /usr/lib, instead of 
> /usr/lib/pgsql, which is desired.

Okay, that problem is gone in current sources, anyway (createlang no
longer needs to know any absolute paths).

> 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
that this is worth your worrying about.  But by the same token, I
wouldn't have a problem with applying that change to the masters ---
surely there are as many systems where '/usr/bin/perl' is correct as
there are where the other is correct.  (In fact, a quick grep shows that
we have more '/usr/bin/perl' than '/usr/local/bin/perl' in the
distribution, so your claim that they're all the latter is mistaken.
We should certainly try to make them consistent, whichever is
preferred.)

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

> Now to the regression tests.  First off, I:
>  define sed-command
> -sed -e 's,@abs_srcdir@,$(abs_srcdir),g' \
> -    -e 's,@abs_builddir@,$(abs_builddir),g' \
> +sed -e 's,@abs_srcdir@,/usr/lib/pgsql/test/regress,g' \
> +    -e 's,@abs_builddir@,/usr/lib/pgsql/test/regress,g' \
>      -e 's/@DLSUFFIX@/$(DLSUFFIX)/g' $< >$@
>  endef

Clearly, this needs to be generalized ...

> Then, I:
> -   AS '@abs_builddir@/regress@DLSUFFIX@'
> +   AS '/usr/lib/pgsql/test/regress/regress.so'
> everywhere that is used, along with its likenesses pointing to refint.so and 
> autoinc.so, which I prebuild and stuff into /usr/lib/pgsql/test/regress.  

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.  IMHO we
could have "make installcheck" copy the .so files to $LIBDIR, 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?)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Large queries - again...