apt-get install without precise PG_VERSION (PG_MAJOR is enough?)

[arthurzenika]

There seems to be a lot of people bumping into "Not Found" errors when building their images (#185, #145, #124, #96, #95, #63). What is the argument for keeping track for precise PG_VERSION in the dockerfile ?

Would a patch like the following be of interrest ?

  	&& apt-get install -y postgresql-common \
 	&& sed -ri 's/#(create_main_cluster) .*$/\1 = false/' /etc/postgresql-common/createcluster.conf \
 	&& apt-get install -y \
-		postgresql-$PG_MAJOR=$PG_VERSION \
-		postgresql-contrib-$PG_MAJOR=$PG_VERSION \
+		postgresql-$PG_MAJOR \
+		postgresql-contrib-$PG_MAJOR \
 	&& rm -rf /var/lib/apt/lists/*

This is a better fit for our needs, are we the only ones ?

Or should http://apt.postgresql.org have a more conservative archive of previous minor versions ? It would then make sense to keep a specific PG_VERSION in there...

If there is a need for specific minor PG_VERSION out there, could there be two separate Dockerfiles for the two uses ?

cc @douardda

[yosifkit]

We have the specific version because of how the images are built and tagged and we want to ensure that the version number in the docker image tag is the version that is installed in the image or the image should fail to build. What is the reason for building the images yourself rather than just pulling them from the hub?

For more information, see the Repeatability section in the official-images repo.

[tianon]

Indeed, when we build and tag an image as postgres:9.6.1, for example, we need to make sure that what we built actually contains PostgreSQL 9.6.1 (and not accidentally 9.6.2 instead), and if it's not possible to satisfy that need, the build must fail. If PostgreSQL upstream modified the way they manage their APT repo to continue to include older versions, this wouldn't have quite the same downstream effect, but unfortunately this is the best we can do. Hopefully that helps explain a little better why we have to do this! 👍