Received: from mx.nixnet.email (mx.nixnet.email [5.161.67.119]) by gbr-app-1.alpinelinux.org (Postfix) with ESMTPS id BDAAB225C4E for <~alpine/users@lists.alpinelinux.org>; Mon, 18 Nov 2024 23:20:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mx.nixnet.email (Postfix) with ESMTPSA id 50B937D32D; Tue, 19 Nov 2024 00:20:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pwned.life; s=202002021149; t=1731972000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v5uuWV54di+FJhDBru/9yoW/ysEyVkLFqNPhvmTpmFw=; b=RGolsneBw5hVuPf0zFaV5Qy+3AORGlEclMenilUtzFuN8jh/+2W5X4Hv6/5/HaLn+CKyBr Re4gkxl/xJ3Ij8H9NjnAp+RHrbZxnH2A87b7rz57MJtTpFudRMdGALY+AT7kcWxWt09DOn R96MhxmReES+qVb2EqXAjj27qTHXvvk= 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: Subject: Re: Multiarch container builds, version pinning, and package retention policies are fundamentally incompatible From: "fossdd" To: "Nadia Santalla" , <~alpine/users@lists.alpinelinux.org> X-Greeting: Hi mom! Look, I'm in somebodys mail client! X-Mailer: aerc 0.18.2-0-ge037c095a049 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