Skip to content

[Feature]: Relax package version pinning in container images #176

Description

@Haralishev77

Problem or motivation

Some system dependencies in Dockerfiles are pinned to exact package versions, including distribution-specific revisions. For example:

libprotobuf-dev=3.21.12-8.2ubuntu0.3

Exact package revisions are frequently replaced in Linux distribution repositories by newer rebuilds, security updates, or maintenance revisions. Once the pinned revision is removed from the configured repository, the container build fails even though a compatible version of the same package is still available.

This causes recurring build failures and requires frequent manual updates to Dockerfiles. In practice, dependency pins may need to be changed almost every week without any corresponding change in the package API or required functionality.

The problem is not specific to Ubuntu or libprotobuf-dev. It applies generally to container images based on Debian, Ubuntu, and other distributions where package revisions change over time.

Proposed solution

Avoid pinning system packages to complete distribution-specific versions unless an exact version is required for compatibility or reproducibility.

By default, package versions should be constrained only to the required major and minor version. Distribution-specific revisions, rebuild numbers, and patch revisions should remain flexible.

For example, replace an exact pin such as:

libprotobuf-dev=3.21.12-8.2ubuntu0.3

with a constraint that accepts compatible releases from the required version line, for example:

libprotobuf-dev=3.21.*

The exact syntax may depend on the package manager and base distribution. The intended policy is:

  • pin the major and minor version required for compatibility;
  • allow compatible patch releases and distribution package revisions;
  • use exact version pins only when there is a documented technical reason;
  • apply the same policy consistently across all Dockerfiles and container images.

This should reduce unnecessary build failures while still preventing unexpected major or minor dependency upgrades.

Area

Other

Alternatives considered

No response

Additional context

No response

Metadata

Metadata

Assignees

Labels

DockerSome changes in DockerenhancementNew feature or request

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions