Thread: Missing userland binaries for PostGIS 2.1

Hello Mike,

On 01/24/2016 05:22 PM, Mike Dillon wrote:
> It looks like the apt.postgresql.org <http://apt.postgresql.org> repo
> was recently updated to have PostGIS 2.2 packages. I build a relatively
> popular Docker image for PostGIS, so this was great to see since it's
> something users have been asking to have for some time
> (see https://github.com/appropriate/docker-postgis).

Cool, thanks. And yes, while postgis-2.2 has been released a while ago,
it's not uncommon for it to take a while until it arrives in Debian
testing. In this particular case, 2.2.0 isn't even fully compatible to
2.2.1, so I decided to not upload 2.2.0 to pgapt at all.

> However, it looks like in the process of updating the repo, version 2.1
> of the "postgis" package was removed.

We are providing only exactly one postgis version at a time, so I
wouldn't say it's removed, but upgraded.

Note that an installed postgis-2.1 extension is guaranteed to continue
to work even after an upgrade. We urge you to upgrade the extension
ASAP, though. This is explained in the NEWS file.

> This means that I can no longer
> build an image for PostGIS 2.1 on older Postgres versions that includes
> the PostGIS userland binaries.

We (pgapt) don't currently provide snapshots of the pgapt archive, which
I think is essentially what you'd want for reproducible Docker images.
You currently have to take care of that for yourself, sorry.

> I understand the difficulty of providing both a 2.2 package and a 2.1
> package in the same repo since there is no version number in the package
> name (e.g. "postgis-2.1" and "postgis-2.2")

Not only that, but postgis itself doesn't allow parallel installations
of multiple versions of the extension. Consider 'CREATE EXTENSION postgis;'.

(Granted, we could in theory still provide multiple conflicting
packages. I don't see much value in that, though.)

> so I'm wondering how much
> of a loss it is to no longer have the userland binaries. I personally
> don't use those binaries, so I can't be sure of the impact of simply
> removing them from the Docker image.

To me, removing them from an old image sounds like a bad idea. Also note
that the postgresql-X.Y-scripts only works with the newest version of
the extension. As noted in the NEWS file, you won't be able to create an
old version of the extension after an upgrade.

Why don't you simply upgrade to Postgis 2.2? It's not like the old image
is vanishing.

If you separate code and data containers, as is common in the Docker
world, it might be sensible to provide postgresql-X.Y-postgis-2.1 and
postgresql-X.Y-postgis-2.2 in the code container. That way, users can
upgrade their code container(s) and run it against their data - no
matter which version of the extension their data container is referring to.

Regards

Markus Wanner

Mike,

On 01/25/2016 09:39 PM, Mike Dillon wrote:
> Right now, the EOL listing
> <http://www.postgresql.org/support/versioning/> on Postgresql.org lists
> version 9.1 through 9.5 as supported. As such the "postgres" image in
> the Docker Hub Official Images program also supports those versions.
>
> Given that PostGIS 2.2 is only available for 9.4 or 9.5

pgapt should currently offer postgis-2.2 for Postgres 9.1 to 9.5

> from what I can
> tell, the only option for those who want to use PostGIS with older
> versions of Postgres is for them to install PostGIS 2.1. Because there
> is not a 2.1 version of the "postgis" Debian package in pgapt, it's not
> possible to install userland binaries for those releases.

That's correct, but applies only for 9.0, I think.

Again, I suspect the binaries are less of a problem, as those should be
backwards compatible. The missing scripts package is more severe, in
this case. Plus the lack of security upgrades for older postgis versions.

> The reason I can't just upgrade to 2.2 is that I have docker-postgis
> images for the older supported versions of Postgres that don't support
> PostGIS 2.2 (i.e. 9.1, 9.2, and 9.3). So if a security update comes
> through for one of those Postgres releases that cause the "postgres"
> image on Docker Hub to be rebuilt, I'll no longer be able to install a
> compatible version of PostGIS on top of them (unless I just install the
> extension and omit the userland binaries).

Yes, those are separate packages. Just install
postgresql-X.Y-postgis-2.1, and there it is.

>     If you separate code and data containers, as is common in the Docker
>     world, it might be sensible to provide postgresql-X.Y-postgis-2.1 and
>     postgresql-X.Y-postgis-2.2 in the code container. That way, users can
>     upgrade their code container(s) and run it against their data - no
>     matter which version of the extension their data container is
>     referring to.
>
>
> This is in fact what my image does. However, if I have to rebuild the
> Postgres 9.3 + PostGIS 2.1 image for any reason, that's no longer
> possible unless I omit the userland binaries from the "postgis" package.

Sure, just install the postgresql-X.Y-postgis-scripts and all
postgresql-X.Y-postgis-M.N packages available. That should cover most
use cases, I think. Including security fixes in PostgreSQL. Just don't
think of it as a "Postgres 9.4 + PostGIS 2.1", but just a "Postgres 9.3
+ PostGIS" image.

Regards

Markus Wanner