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

[cc: to GENERAL replacedby cc: to HACKERS]
On Friday 20 July 2001 17:14, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > The biggest patching by far is
> > in the regression tests, which really are not designed to live outside
> > the source tree, but can be munged into shape fairly easily.

> Peter has already done good work in making it possible to build outside
> the source tree. ISTM that it would make logical sense to allow
> regression tests to be run outside the source tree as well, as long as
> the changes don't break the existing procedures. I have not looked at
> your patches in this area --- what do they need to do, exactly?

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. So the first patch is:
diff -uNr postgresql-7.1.2.orig/src/bin/scripts/createlang.sh
postgresql-7.1.2/src/bin/scripts/createlang.sh
--- postgresql-7.1.2.orig/src/bin/scripts/createlang.sh Sun Feb 18 13:34:01
2001
+++ postgresql-7.1.2/src/bin/scripts/createlang.sh Wed Jun 13 16:00:55 2001
@@ -164,7 +164,7 @@
# Check that we have PGLIB
# ----------
if [ -z "$PGLIB" ]; then
- PGLIB='@libdir@'
+ PGLIB='/usr/lib/pgsql'
fi

# ----------

To handle that, as $PGLIB does indeed point to /usr/lib/pgsql for most
things, but a user is not guaranteed to set the envvar. @libdir@ points to
/usr/lib during the build, as it should -- but createlang's PGLIB and
autoconf's libdir are not equal.

This is desireable because the procedural languages aren't generally loadable
into any arbitrary program by ld.so; rather, they are postgresql-specifc
modules, warranting a separate directory under FHS. This patch fixes the
RPM-specific case only, obviously, as /usr/lib/pgsql is going to be the wrong
choice for non-RPM users :-).

Next, we have patches to make the perl client honor RPM_BUILD_ROOT (otherwise
known as DESTDIR). I'm omitting them here, as Peter has mentioned a build
overhaul for the perl and python clients to make them do DESTDIR and in
general fit in better with the rest of the package.

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. I only ship
postgresql-7.1.2/src/interfaces/perl5/test.pl at this time.

Now to the regression tests. First off, I:
diff -uNr postgresql-7.1.2.orig/src/test/regress/GNUmakefile
postgresql-7.1.2/src/test/regress/GNUmakefile
--- postgresql-7.1.2.orig/src/test/regress/GNUmakefile Wed Apr 4 17:15:56
2001
+++ postgresql-7.1.2/src/test/regress/GNUmakefile Wed Jun 13 16:00:55 2001
@@ -67,8 +67,8 @@
abs_builddir := $(shell pwd)

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

since the tests aren't in the build tree anymore, but in
/usr/lib/pgsql/test/regress. Well _technically_ they're really NOT in
/usr/lib/pgsql/test/regress, but in DESTDIR/usr/lib/pgsql/test/regress during
the build -- but they will be executed in the coded location after the RPM
installation.

Then, I:
- AS '@abs_builddir@/regress(at)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.
Although /usr/lib/pgsql would be a more consistent place, I guess. That
construct is used in
postgresql-7.1.2/src/test/regress/input/create_function_1.source and
ostgresql-7.1.2/src/test/regress/output/create_function_1.source.

Finally, I patch postgresql-7.1.2/src/test/regress/pg_regress.sh:
@@ -69,7 +69,7 @@
: ${inputdir=.}
: ${outputdir=.}

-libdir='@libdir@'
+libdir='/usr/lib/pgsql'
bindir='@bindir@'
datadir='@datadir@'
host_platform='@host_tuple@'

Again, @libdir@ != $PGLIB.

This set is quite a bit smaller than the 7.0.x and 6.5.x sets, thanks in no
small part to Peter's work, as you have already said.

> I think there are really two separate discussions going on here: one is
> whether we shouldn't try harder to roll some of the RPMset diffs back
> into the main sources, and the other is how we can make information
> about some of the popular packages more readily visible/available to the
> developers.

My diffs are nowhere near as large as the debian set. There are other things
I could patch, instead of frobbing in the specfile, though -- things like the
python and perl clients' makefile's DESTDIR ignorance, and the fact that
'make install' puts the procedural languages in /usr/lib instead of
/usr/lib/pgsql. The easy answer: 'Use the --libdir configure switch!' won't
work, though, as I can't just tell configure that libdir needs to be
/usr/lib/pgsql -- libpq.so and friends need to go in /usr/lib!

And I've not tried to make my patches fit the general case as yet -- they
haven't needed to be general in scope.

There is some munging done in contrib that could be put in a patch, though --
in particular, the following construct executes _14_ times....
# some-contrib-module
pushd some-contrib-module
perl -pi -e "s|/usr/lib/contrib|/usr/lib/pgsql/contrib/some-contrib-module|" *
popd

libdir !=$PGLIB, again.

And more path munging for the rserv and earthdistance contrib modules happen.

And the whole contrib tree, since there isn't a good 'make install' that
honors DESTDIR for that tree, gets a kick in the pants to
/usr/lib/pgsql/contrib, from $RPM_BUILD_DIR/postgresql-7.1.2.

> Peter's stance on the latter seems to be "go look at the
> packagers' sites", which is defensible, but that's the current approach
> and I think it's not working.

The biggest RPM difference is simply where things are put. Otherwise there's
a mere handful of sysadmin scripts added.

With the specfile, README.rpm-dist, and the other scriptfiles in a CVS
module, I'd sleep better, knowing that someone else might have an easier time
picking things up if I kick the big bucket.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11