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

[Ole Streicher]

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.

Best regards

Ole

On 30.08.2017 16:26, Ole Streicher wrote:
> Hi Christoph,
> 
> On 30.08.2017 15:50, Christoph Berg wrote:
>> Re: Ole Streicher 2017-08-30 <d70bc62a-4f92-cb62-45d7-dce974e2c266 at debian.org>
>>> The idea here is to have just one binary package, containing the shared
>>> libraries for all supported versions. Extensions are usually small, so
>>> combining them in one package will not hurt. So, there would no
>>> "postgresql-9.6-q3c" package anymore, d/control.in is removed, and
>>> d/control is fixed (for one release). [...]
>>
>> That is true, but it's totally different from what we have been doing
>> so far. We would need to update all packages, and providing the
>> necessary (?) transitional packages for existing users will be
>> difficult.
> 
> There is no need to update quickly: if just the dependency variable
> creation is integrated in pg_buildext, then the maintainer can still
> choose between the current approach and the single-package approach. It
> is just a matter of policy then.
> 
> Transitioning should just be possible with an additional field
> 
> Provides: postgresql-9.6-debconf, postgresql-10.0-debconf [...]
> 
> which also could be supported by a variable {postgresql:Provides},
> created similarly to {postgresql:Depends} field.
> 
>> If a PG version goes out of support, the new package version wouldn't
>> contain the module anymore, even if users are still using that PG
>> version on their system. (Think Debian dist-upgrades.)
> 
> And if a postgresql version goes out of support, then I would suppose
> that the postgresql-XX server package is removed as well? Then, they
> couldn't upgrade the package because of the missing postgresql
> dependency, and they couldn't upgrade in the old scheme.
> 
> But I must say I have no idea how upgrades for Postgresql work, there
> may be some problems.
> 
>> It would also prevent (easily) building packages against beta/devel PG
>> versions (10 and 11 at the moment). Or these packages would need to
>> include the "normal" PG versions from the normal packages, plus the
>> extra versions.
> 
> The only difference is that all builds are combined into a single
> package. So, whatever can be built in the current scheme, can also be
> built then. If "pg_buildext supported-versions" offers experimental
> packages, they are also included.
> 
> Best regards
> 
> Ole
>