The Problem with Docker and Alpine’s Package Pinning

As a big fan of Alpine Linux, the author uses it in many Docker images because of its extremely small size, making it ideal for container environments.

When trying to build an outdated project, the Alpine package manager apk fails, revealing a surprising issue.

One of Docker’s greatest advantages is clear reproducibility: the same image yields identical results regardless of where or when it runs, and this consistency is also crucial during image builds.

To achieve consistent builds, dependencies must be pinned to specific versions; installing a generic package like nodejs is insufficient without specifying an exact version such as [email protected] .

Alpine Linux supports two pinning methods: repository pinning and package pinning. Each Alpine release (e.g., 3.7) has its own package repository, allowing you to lock the repository to a particular Alpine version so you always receive the latest packages for that release.

Package pinning lets you fix a package to an exact version (e.g., nodejs-1.2.3 ), which sounds ideal.

However, Alpine does not retain old packages. When the author tried to install postgresql-dev-10.2-r0 , the repository had already moved to postgresql-dev-10.3-r0 , producing the following error:

ERROR: unsatisfiable constraints:
postgresql-dev-10.3-r0:
br eaks: world[postgresql-dev=10.2-r0]

This forces developers to rely on repository pinning, but rebuilding the image may still pull newer package versions, potentially introducing unexpected changes.

The author wishes Alpine behaved like PyPI or npm, keeping all historic versions so that version pinning would work reliably, and advises adding extensive unit tests when dealing with Alpine’s package updates.