[Pkg-postgresql-public] psqlodbc 1:09.06.0500-1 MIGRATED to testing

2017-09-23 Thread Debian testing watch 
FYI: The status of the psqlodbc source package
in Debian's testing distribution has changed.

  Previous version: 1:09.06.0410-1
  Current version:  1:09.06.0500-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

[Pkg-postgresql-public] ora2pg 18.2-1 MIGRATED to testing

2017-09-23 Thread Debian testing watch 
FYI: The status of the ora2pg source package
in Debian's testing distribution has changed.

  Previous version: 18.1-1
  Current version:  18.2-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

[Pkg-postgresql-public] PostgreSQL 10 transition

2017-09-23 Thread Christoph Berg 
Re: To Ole Streicher 2017-09-23 <20170923194140.k4xeait35ofkc...@msg.df7cb.de>
> > may I ping you here? Postgresql-10 just arrived in unstable (great,
> > thanks); but I would now rather like to convert to single (and
> > bin-NMU-capable) packages instead of adding postgresql-10-q3c now, as it
> > is done f.e. for Python packages.
> > 
> > I would just do this for my own packages (pqsphere and q3c), which would
> > allow to collect experiences; but ofcourse I don't want to shoot into
> > your feet with the packaging at the postgresql site.

Btw, the transition tracker is here:

https://release.debian.org/transitions/html/postgresql-10.html

Christoph

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

2017-09-23 Thread Christoph Berg 
Re: Ole Streicher 2017-09-22 
> Hi Christoph,
> 
> may I ping you here? Postgresql-10 just arrived in unstable (great,
> thanks); but I would now rather like to convert to single (and
> bin-NMU-capable) packages instead of adding postgresql-10-q3c now, as it
> is done f.e. for Python packages.
> 
> I would just do this for my own packages (pqsphere and q3c), which would
> allow to collect experiences; but ofcourse I don't want to shoot into
> your feet with the packaging at the postgresql site.

The plan seems sensible, so please go ahead, it will be an interesting
experiment. The plethora of mini packages we have now isn't ideal.

(While uploading the first batch of PG10 packages, I rediscovered the
fact that the pgagent package is already using such a scheme:

Package: pgagent
XB-Postgresql-Version: ${Postgresql:Version}
Postgresql-Version: 9.2 9.3 9.4 9.5 9.6

The package is pretty small, though, pgagent's extension part is SQL
only, and version-agnostic, only the pgagent client binary needs to be
compiled, and doesn't vary between versions.)

My main concern is supporting upgrades cleanly. Imagine "your" package
had already been around in jessie, and the user had postgresql-9.4 +
postgresql-q3c installed where q3c provided the 9.4 extension. Now the
user upgrades to stretch, gets postgresql-9.6 installed (e.g. via
postgresql.deb), the 9.4 cluster will still work, but the upgraded
postgresql-q3c package from stretch suddenly doesn't provide the 9.4
anymore, but only 9.6, rendering q3c broken in the 9.4 cluster.

Maybe we could just claim that the user should upgrade their database
at the same time, and for many extensions this will not be a problem.
But for extensions providing datatypes (I think that includes q3c),
the .so module is needed for dumping the old data, so at least
dump-restore upgrades are affected. pg_upgrade should still work,
though. (Making pg_upgradecluster use that by default is another
story.)

Christoph

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public