Message-ID: <5d8a64d114f24495584cc4b646aa80d090631ffa.camel@santalla.io>
Subject: Multiarch container builds, version pinning, and package retention
 policies are fundamentally incompatible
From: Nadia Santalla <nadia@santalla.io>
To: ~alpine/users@lists.alpinelinux.org
Date: Mon, 18 Nov 2024 18:21:26 +0100
Autocrypt: addr=nadia@santalla.io; prefer-encrypt=mutual;
 keydata=mDMEZqa8DhYJKwYBBAHaRw8BAQdA8Zuhl961yt0tiX3JhNa0RPWnPElwryswsXdaPA4jy
 P+0Ik5hZGlhIFNhbnRhbGxhIDxuYWRpYUBzYW50YWxsYS5pbz6ImQQTFgoAQRYhBB7yiOSB3lc3+s
 U7EhiwRbwJ6bUqBQJmprwOAhsDBQkSzAMABQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEBi
 wRbwJ6bUqNo4BAJzbmHsX/YI0osEG15Y7pZ6Erfr5XQXGiRxZX+8MBtatAQCf6ZzYgTnLyr3LGu+v
 3kP23iLzHClFL0quxwazXQipCg==
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hello!

I'm Nadia and I'm a long-since, happy user of alpine for containerized
workloads.

I have recently stumbled across a problem related to multiarch
container images, version pinning, and alpine's package retention
policy (where only the latest version of a package is available for a
given alpine release).

I have a Dockerfile that looks like this:

```Dockerfile
FROM --platform=3D$TARGETPLATFORM alpine:3.20.3

RUN apk --no-cache add --repository community chromium-
swiftshader=3D130.0.6723.116-r0
# ...
```

This Dockerfile is currently (2024-11-18) unbuildable in a multiarch
context, because the chromium-swiftshader package has a version drift
across architectures:
For x86_64, the last (and only available) version is 131.0.6778.69-r0=20
https://pkgs.alpinelinux.org/packages?name=3Dchromium-swiftshader&branch=3D=
v3.20&repo=3D&arch=3Dx86_64&origin=3D&flagged=3D&maintainer=3D
For aarch64, it is 130.0.6723.116-r0
https://pkgs.alpinelinux.org/packages?name=3Dchromium-swiftshader&branch=3D=
v3.20&repo=3D&arch=3Daarch64&origin=3D&flagged=3D&maintainer=3D

I'm sure the issue with chromium-swiftshader is being worked on, and
that is not what I want to surface here.

I would like to bring attention to the problem that when and if this
happens for a given package, container build pipelines that try to
build for multiple architectures will break without a fix: Updating to
the latest version is not possible, as it is not present in the
outdated architecture, and keeping the outdated version is not possible
either, as it is no longer installable in the updated architecture.

I believe version pinning is established as a good practice in the
industry, and thus I think this use case needs some consideration from
the Alpine side. Even if not very common, packages breaking for certain
architecture is something that can definitely happen, and I think it
would be great for alpine to handle this more gracefully.

I'd love to hear if this has happened to someone else, and how they are
handling it, and/or what's the point of view of alpine developers on
this issue.

BR,
- N