Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Jakub Jirutka <jakub@jirutka.cz>
Mime-Version: 1.0 (1.0)
Subject: Re: Multiarch container builds, version pinning, and package retention policies are fundamentally incompatible
Date: Tue, 19 Nov 2024 02:09:11 +0100
Message-Id: <E83940A1-CC1C-456C-9F38-539B051B260C@jirutka.cz>
References: <D5POTZXFUK1H.2LUELCKMXTWER@pwned.life>
Cc: Nadia Santalla <nadia@santalla.io>,
 ~alpine/users@lists.alpinelinux.org
In-Reply-To: <D5POTZXFUK1H.2LUELCKMXTWER@pwned.life>
To: fossdd <fossdd@pwned.life>

Hi

> Arch Linux has a archive for old packages
> (https://wiki.archlinux.org/title/Arch_Linux_Archive). Someone could do
> the same,

I=E2=80=99m doing weekly snapshots on https://mirror.fel.cvut.cz/alpine/snap=
shots (for future scientific use), but only for x86_64.

> but honestly this is just promoting bad behaviour and nobody should rely o=
n it.

Exactly. Your approach of pinning versions of packages in docker files is ju=
st not compatible with the release model of Linux distros. We have stable br=
anches where you can rely on backward compatibility of package upgrades and g=
et security fixes.

Jakub

Sent from mobile phone

> On 19. 11. 2024, at 0:20, fossdd <fossdd@pwned.life> wrote:
>=20
> =EF=BB=BFOn Mon Nov 18, 2024 at 6:21 PM CET, Nadia Santalla wrote:
>> Hello!
>=20
> Hi!
>=20
>>=20
>> I'm Nadia and I'm a long-since, happy user of alpine for containerized
>> workloads.
>=20
> That's nice!
>=20
>>=20
>> 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).
>>=20
>> I have a Dockerfile that looks like this:
>>=20
>> ```Dockerfile
>> FROM --platform=3D$TARGETPLATFORM alpine:3.20.3
>>=20
>> RUN apk --no-cache add --repository community chromium-
>> swiftshader=3D130.0.6723.116-r0
>> # ...
>> ```
>>=20
>> 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
>> 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
>>=20
>=20
> Usually all architectures have the same version. Of course some
> inconsistencies may happen because builder some are faster than others.
>=20
> Particulary the last days the arm builders were failing, see this
> incident: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10832=
/
>=20
>> I'm sure the issue with chromium-swiftshader is being worked on, and
>> that is not what I want to surface here.
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> For example if we update two packages in a single MR, and the former
> 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.
>=20
> 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).
>=20
> 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.
>=20
>>=20
>> 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.
>>=20
>> BR,
>> - N