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

Ole Streicher olebole at debian.org
Wed Aug 30 14:26:12 UTC 2017


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



More information about the Buildd-tools-devel mailing list