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-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
>
