[buildd-tools-devel] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Antonio Terceiro]

On Mon, Mar 27, 2017 at 10:44:22AM +0200, Christoph Berg wrote:
> Re: Antonio Terceiro 2017-03-27 <20170326234116.xkcx7wjcyrqsxnmb at debian.org>
> > As you said, it has the issue of not helping with upgrades.
> 
> True...
> 
> > What if, instead of the versioned packages, you provided unversioned
> > package names, and each package contained one .so for each supported
> > PostgreSQL version? It seems that postgresql-server-dev-all exists for
> > exactly this purpose ...
> 
> This has the problem that the set of supported versions varies over
> time, and that it's different in Debian, and elsewhere. We would be
> shipping a 9.6-only package in Debian, and a package containing
> everything from 9.2 to 9.6 on apt.postgresql.org. The necessary
> dependencies would be non-trivial I'd think.

We do exactly that in Ruby, and it is manageable. When the set of
supported versions change, we update the list in a central place
(ruby-defaults), and binNMU/fix existing modules. We also make the
dependencies in such a way that a package that contains modules for more
than one version depends on the stuff from _one_ of the versions, but
not from all of them.

Each context (Debian, apt.postgresql.org) could have a different set of
supported versions via something similar to dpkg-vendor.

Are you opposed to this in principle? Or, would you be willing to
support this if the necessary patches are written? (not saying I will do
that, or at least not in the short term :-))

> Also this would make it impossible to provide modules packages for the
> upcoming PostgreSQL 10 version, because "postgresql-debversion.deb" is
> already in use there.

Does this mean that for PostgreSQL 10+ the module packages will have no
version numbers in their names? Or is that just something you reserve
for the very latest version at the time?

> I agree that the situation is not optimal, but I think what we have
> now is the best we could get to over the past years. Unfortunately
> this means you'll need to encode some knowledge about the current
> PostgreSQL server version in your deployment recipes.

It also means that upgrades don't just work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170327/f9e82d7f/attachment.sig>