[Pkg-postgresql-public] [pgsql-pkg-debian] Debian packaging of the q3c and pgsphere extensions

Christoph Berg myon at debian.org
Mon Aug 7 19:29:24 UTC 2017


Re: Ole Streicher 2017-08-07 <ee77cbbe-a170-8bfa-1a80-883987b026ee at debian.org>
> > ... and a minimal debian/tests/control file. (See pg_buildext(1))
> 
> Ah, so there are no built time checks possible "just" CI test, right?

Unfortunately, right. The problem is (among others) that "CREATE
EXTENSION" wants to read the $extension.control file from
/usr/share/postgresql/$version/extension, and that part is not
configurable. (There's more path problems, but the others should be
possible to work around without patching the PostgreSQL server.)

> The tests worked for me, so I didn't change this.

Not sure what was wrong on my notebook here, but that doesn't really
matter anyway :)

The tests seem to work for the apt.postgresql.org jenkins as well.
(Still building, the tests are pretty slow and there's 5 "9.x"
versions to cover.)

> Thanks for you help! Everything seems to work now, so I uploaded q3c:
> 
> https://ftp-master.debian.org/new/postgresql-q3c_1.5.0-1.html

Nice :)

> For pgsphere, I had less success; the tests fail currently. For me
> (being still a strawmen), this looks like an upstream problem, so I am
> hoping for a response from there. If you like, you can however have a
> look as well; just to double-check that it is not a packaging problem:

I'm just browsing the source - I think core of the problem is that
pgsphere was last updated in 2010 when PostgreSQL 9.0 was current -
that was the last version without "CREATE EXTENSION" support, so it's
still using the old style of directly loading the function definitions
into the server, see sql/init.sql: "\i pg_sphere.sql". 9.0 is EOL, so
you don't need to support that style anymore.

Because of the out-of-tree build, pg_sphere.sql is not in $PWD, so
psql (or pg_regress) doesn't find it when running the tests:
regression.diffs says "pg_sphere.sql: No such file or directory".
(The PostgreSQL project still likes "context" diffs for this...)

The ideal way forward would be if you convert the module to a proper
extension. Basically you just need to write a trivial pg_sphere.control
file (see q3c for an example), and install pg_sphere.sql as
pg_sphere--1.sql. (The number there is sort of the SONAME of the
extension and might or might not correlate with the upstream version
number.)

sql/init.sql could then simply say "CREATE EXTENSION pg_sphere;".
(And expected/init.sql needs to match.)

If you expect a non-trivial number of users to have installed
pg_sphere using the "\i" method, you could also provide a
pg_sphere--unpackaged--1.sql file to allow "importing" the module
objects into an extension using "ALTER EXTENSION ADD" commands. The PG
docs cover that case as well:

https://www.postgresql.org/docs/9.6/static/extend-extensions.html

Christoph



More information about the Pkg-postgresql-public mailing list