Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 19 Nov 2024 00:19:58 +0100
Message-Id: <D5POTZXFUK1H.2LUELCKMXTWER@pwned.life>
Subject: Re: Multiarch container builds, version pinning, and package
 retention policies are fundamentally incompatible
From: "fossdd" <fossdd@pwned.life>
To: "Nadia Santalla" <nadia@santalla.io>,
 <~alpine/users@lists.alpinelinux.org>
References: <5d8a64d114f24495584cc4b646aa80d090631ffa.camel@santalla.io>
In-Reply-To: <5d8a64d114f24495584cc4b646aa80d090631ffa.camel@santalla.io>

On Mon Nov 18, 2024 at 6:21 PM CET, Nadia Santalla wrote:
> Hello!

Hi!

>
> I'm Nadia and I'm a long-since, happy user of alpine for containerized
> workloads.

That's nice!

>
> 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=
=3Dv3.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=
=3Dv3.20&repo=3D&arch=3Daarch64&origin=3D&flagged=3D&maintainer=3D
>

Usually all architectures have the same version. Of course some
inconsistencies may happen because builder some are faster than others.

Particulary the last days the arm builders were failing, see this
incident: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10832/

> 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.

If a version breaks, forcing a specific version isn't a fix, it's more
like a temporary workaround. I wouldn't use this in production, most
importantly you must remind you again to remove the constraint.
Otherwise you end up with way more problems than you probably had
before.

Partial upgrades are always tricky and only lead to problems. It's a lot
easier if we can safely assume for new commits that all systems are on
that tree.

For example if we update two packages in a single MR, and the former=20
package depends on a new version of the latter package, we need to add
the version constraint to the package dependency. This effort, plus
reviewing bad constraints and removing old constraints, is A LOT and is
not worth the effort.

Addionally adding support for old versions in our repositories doubles
(or more?) the disk size of the mirrors which is not doable for most
mirrors. (we already disable most -dbg packages due to size issues).

Arch Linux has a archive for old packages
(https://wiki.archlinux.org/title/Arch_Linux_Archive). Someone could do
the same, but honestly this is just promoting bad behaviour and nobody
should rely on it.

>
> 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