[Pkg-postgresql-public] autopkgtest support

[Christoph Berg]

Hi,

over the holidays I've been working on bringing more autopkgtest
support into the PostgreSQL packages in Debian. First victim was
pgbouncer which now has a simple connection test [1]. This needs a
running PostgreSQL server, so I wrote a script that will launch a
throw-away instance [2].

[1] http://anonscm.debian.org/gitweb/?p=pkg-postgresql/pgbouncer.git;a=blob;f=debian/tests/connect;h=109f6a5414009fe033684c8df9b419ccbdfafdc5;hb=HEAD
[2] http://anonscm.debian.org/loggerhead/pkg-postgresql/postgresql-common/trunk/annotate/head:/pg_virtualenv

I haven't uploaded any of that yet (except for some test packages in
the testing distributions on apt.postgresql.org), and I'd like some
feedback if the general approach here is right.

Does that pg_virtualenv implementation make sense? Should that be
shipped in /usr/bin/ in postgresql-common or elsewhere? (Can/should we
reasonably drop privileges there?)


Along the same line, I've updated postgresql-common's
debian/tests/control to depend on PG 9.1 and 9.2. I realize that this
will break unstable (but we are uploading to experimental) and
probably Ubuntu (that's why I am asking here). The reason why there
are version-specific dependencies in that file is because we do not
have meta packages for plperl/python/python3/tcl, and depending on the
virtual package names (Provides: postgresql-plperl) doesn't really
work. (I tried that in r1246 because it worked on my notebook, but it
broke on the pgdg jenkins build.)

One way to fix this could be to just provide the meta packages (and
then hope the existing Provides: fields in the current packages do not
mess up that approach).

Alternatively, we could have some "postgresql-all" meta package that
pulls in contrib/plperl/whatever. The testsuite would then just depend
on that one. The extra question to answer here is if there should be
an -all package per PostgreSQL version (postgresql-9.1-all), or one
that pulls in all packages for all supported PostgreSQL versions (that
would be a long list of dependencies on PGDG, but that's ok). Or we
can have both -version-all and -all-all meta packages, if that's not
too confusing...

I'd tend to the pg-all-all variant, because that's what the regression
tests for multi-version extension packages need. (Except without the
PL packages, so that could be postgresql-server-all...)

Does any of that look sane? :)


Oh, and I'd like to put autopkgtest stuff into the individual server
packages. That could mean that postgresql-common shouldn't include
server tests, or we declare that the place where upgrades are being
tested, which naturally wouldn't inside the single-version tests in
the server packages.

Christoph
-- 
cb at df7cb.de | http://www.df7cb.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20121231/0bdaa270/attachment.pgp>