PostgreSQL transition ahead

[Martin Pitt]

(Sorry if you got this mail several times, I just CC'ed it to every
affected binary package).

Hi fellow Debian developers!

Three months ago I announced the first alpha versions of the new
architecture of the PostgreSQL packages [1] in experimental. Now, a
few months later, they are mature enough to be used in actual
production environments. In addition, Sarge is out of the door (YAY!),
so it's high time to break unstable again. :-)

The packages have lived in Debian experimental for a while now and are
tested by several people (who also write bug reports). Currently they
have no open bugs and support all the features that the Sarge version
did. However, the new structure is much easier to maintain and
develop, and also offers many new features for users (multi-version,
multi-cluster, painless upgrades, see [2]).

I will upload the new packages to unstable very soon.  This has a
reasonably big impact to all packages that depend/build-depend on
PostgreSQL since the package structure changed a bit:

(1) postgresql-dev was split into libpq-dev (for client apps like
    postfix or pygresql) and postgresql-server-dev-<version> for server
    extensions (like postgresql-plruby and postgresql-ocaml).

(2) PostgreSQL 8.0 brought a new SONAME for libpq (libpq4), which
    removed a few symbols which were only intended for internal use,
    but were used nevertheless by some client apps (like "psql").
    libpq4 can talk to all PostgreSQL servers back to 7.3 (same like
    libpq3).

(1) makes all packages FTBFS that build-depend on postgresql-dev (I
CC'ed all affected packages). These need to be changed to depend on
libpq-dev, and make buildable again. This will automatically care for
(2) since libpq-dev makes the package depend on libpq4 then.

The steps to adapt a client-side application to the new structure are:

 1. Change the build-dependency postgresql-dev to libpq-dev.
 2. Fix include directory path:
  - Very few packages use pg_config to determine include and library
    directories (e. g. pygresql). In this case no additional changes
    should be required any more. pg_config has been there for ages,
    but apparently nobody bothered to use it.
  - If the package does not use pg_config, then the ideal solution is
    to convert it to do so. This is easily possible for almost all
    packages (e. g. in debian/rules, add a configure option like
    --with-pgsql-include=`pg_config --includedir`).
  - If the packaging hardcodes include paths and has a crappy build
    system (cyrus-sasl2 was a pretty nonstandard one), then the quick
    fix is to hardcode the path for now (/usr/include/postgresql/8.0);
    however, this is not very robust, and it would be nice to
    eventually convert the package to use pg_config.
 3. Test build. As a rule of thumb, if the package builds, it works.
    libpq-dev mainly changed paths and has a new library SONAME
    behind (libpq4), but the client library did not change any
    interface and thus should be fully backwards compatible.
 4. Upload. :-)

I already did these steps for a fair number of packages. So if you
maintain one of the packages that have a debdiff at [3], you are lucky
and only need to apply the patch there (however, cyrus-sasl2 and
dovecot were nasty cases where the path has been hardcoded for now;
this should be improved). The debdiffs were made for Ubuntu packages
since I could upload them straight away. So the changelog patch will
fail to apply, but the rest should be fine.

The server-side packages are more delicate, though. Ideally they would
be repackaged to build a module for all supported PostgreSQL versions
(i. e. postgresql-7.4-plr, postgresql-8.0-plr, and so on). I will
finish plr soon to show an example of how this is supposed to look
like. Peter Eisentraut will package PL/Java soon. If you maintain such
a package, please consider subscribing to [4] to coordinate the
effort.

Although the new packages will make all the client packages FTBFS, I
will upload them to unstable soon, because:

 * The already built client app debs will just continue to work.
 * There is a clean upgrade path from the old postgresql package to
   the new one (just dist-upgrade).
 * Sid will be broken for a fair amount of time anyway since there are
   more transitions ahead of us (g++ 4.0, dbus, etc.)

This mail already became longer than intended, so if you have any
question, please contact [4] or me personally.

Thanks and have a nice day!

Martin

[1] http://lists.debian.org/debian-devel/2005/03/msg01858.html
[2] http://people.debian.org/~mpitt/postgresql-ng.html
[3] http://people.ubuntu.com/~pitti/postgresql-transition/
[4] http://lists.alioth.debian.org/mailman/listinfo/pkg-postgresql-public

-- 
Martin Pitt              http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developer        http://www.debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20050718/72b3310e/attachment.pgp