Hi Christoph, On 23.09.2017 21:41, Christoph Berg wrote: > Re: Ole Streicher 2017-09-22 <e1f46e5e-aca8-5b45-af4a-e5a3272f9...@debian.org> >> 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.
I just uploaded q3c as a single binary package. pgsphere will follow after some discussion with the main users (hi Markus :-) ) > 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. This can be addressed by introducing Postgresql-versioned Provides. If the q3c package would support f.e. 9.6 and 10, it can have Provides: postgresql-9.6-q3c, postgresql-10-q3c If you then need q3c for a specific version, you can install/depend on this specific version. This also allows a smooth transition between the multi-binary-package approach and the single binary package. This is already implemented in the uploaded version. > 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.) This may indeed need some work; however I need some advice here. Best regards Ole