Hi Christoph, On 30.08.2017 15:50, Christoph Berg wrote: > Re: Ole Streicher 2017-08-30 <d70bc62a-4f92-cb62-45d7-dce974e2c...@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