Received: from mail.nadia.moe (v.tenshi.es [IPv6:2a01:4f8:10a:2ad9::2]) by gbr-app-1.alpinelinux.org (Postfix) with ESMTP id 58785225D16 for <~alpine/users@lists.alpinelinux.org>; Tue, 19 Nov 2024 13:04:20 +0000 (UTC) Message-ID: <c0ff727d04790e33f05f3904ab1c2f60381c84bb.camel@santalla.io> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=santalla.io; s=dkim; t=1732021457; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=UWVPXgnZ/txzCIL2+VkJ+7tFZmhCeNXZV2LuRw7FEK0=; b=EEXIUExgvG4bl42j/+Mjj1lSoWO5NrJLOJdxkNMwcAcI7nB4IOnfYUk/qqPZElw+Pz2mG1 8tu/RKuhT9QRc+xVwXAcqQwejfDxV1UkQwk2KOH/Z5fiZ4neZZmZduMXWWW+40VpSzIbby fED1Y/X/tuQ8fmznRSjUGNUP1iv8/otc2ULQy7eUeFDWgnASXirwbZNT+Jwctf5JwZ2wP7 uWV4s1NCzBJfkwPOl3zXURhwZms4fouziTaD1kYgg1Vi3bksx7hkRKN14tjnm05gxVaMlq e+SYe5VN0CT2DxYlA/pO7MDJXl+2QYvvynbBQfsXIGqgIYd+cgL5cg8+Qxtgtg== Authentication-Results: mail.nadia.moe; auth=pass smtp.mailfrom=nadia@santalla.io Subject: Re: Multiarch container builds, version pinning, and package retention policies are fundamentally incompatible From: Nadia Santalla <nadia@santalla.io> To: Jakub Jirutka <jakub@jirutka.cz>, fossdd <fossdd@pwned.life> Cc: ~alpine/users@lists.alpinelinux.org Date: Tue, 19 Nov 2024 14:04:16 +0100 In-Reply-To: <E83940A1-CC1C-456C-9F38-539B051B260C@jirutka.cz> References: <D5POTZXFUK1H.2LUELCKMXTWER@pwned.life> <E83940A1-CC1C-456C-9F38-539B051B260C@jirutka.cz> 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 X-Spamd-Bar: / Hi Jakub, Fossdd, Thanks a lot for sharing your insights! I think it might be useful for me to elaborate more on why the container and non-container (so-called baremetal, but I'd rather not call it that) use case differs. In the container world, we care *a lot* about images being reproducible: This is one of the reasons why containers were born, after all.=C2=A0Allegedly, we're have still a lot of strides to make regarding byte-to-byte reproducibility, but I believe we'll eventually get there. Regardless of that, what is well-established and even assumed in the container world is the following: If someone builds a container image from a Dockerfile (+ a given set of source files) today, and someone else builds a container image using the same Dockerfile (and same set of source files) next week, the resulting image should _behave the same_. This assumption does not hold if in your Dockerfile, you install (or download, for that matter) binaries or other components without specified version. `apk` (or `apt`) `install` are very much likely to install one thing today and a different one next week. This assumption is heavily ingrained in the container world. To give some examples, Dockerfile liners that are shipped by default in the most popular editors, have rules that explicitly tell you to pin versions in `apk add`: https://github.com/hadolint/hadolint/blob/4ab5d7809325c8de23956a44ca5a1f3c2= 5907faf/src/Hadolint/Rule/DL3018.hs#L20 This is popping up by default on the most popular editors across the world. That being said, I understand this is definitely container-specific. I run arch linux (btw) on my workstations and servers, which has a similar policy as alpine, and I very rarely have had to pin version for a package. I think the "partial upgrades are bad and problematic" is very true for full system installations, but I see it being definitely at odds with container best practices. I think it is good if alpine kept using the same practices it is currently doing, and assume no partial upgrades to keep the maintainer effort required into reasonable levels. But I also think that the container community would appreciate a best-effort approach on helping towards reproducible container builds.=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). I definitely see this cost problem and, while I do not have any idea to magically solve it, maybe I can try with a suggestion to contain it: If old versions are provided for specific, non-general use cases (containers), then perhaps not all mirrors need to support it, and perhaps a single one (like archlinux's archive) could suffice. People who are willing to trade reproducibility for potential dependency breakages in their containers would be able to use it. This email came out way longer than what I was planning, but at least I'm hoping I did a decent job explaining about why we pin version=20 numbers in the container world and how I hope alpine could support that use case better. - Nad