Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 19 Nov 2024 16:13:12 +0100
Message-Id: <D5Q93UHIXUAE.2TSDK67WSPG7T@pwned.life>
From: "fossdd" <fossdd@pwned.life>
To: "Nadia Santalla" <nadia@santalla.io>, "Jakub Jirutka" <jakub@jirutka.cz>
Cc: <~alpine/users@lists.alpinelinux.org>
Subject: Re: Multiarch container builds, version pinning, and package
 retention policies are fundamentally incompatible
References: <D5POTZXFUK1H.2LUELCKMXTWER@pwned.life>
 <E83940A1-CC1C-456C-9F38-539B051B260C@jirutka.cz>
 <c0ff727d04790e33f05f3904ab1c2f60381c84bb.camel@santalla.io>
In-Reply-To: <c0ff727d04790e33f05f3904ab1c2f60381c84bb.camel@santalla.io>

On Tue Nov 19, 2024 at 2:04 PM CET, Nadia Santalla wrote:
> 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 theFuxels same
> Dockerfile (and same set of source files) next week, the resulting
> image should _behave the same_.

That's why we have stable releases. Stable releases only contain
security (and bug) fixes.=20

>
> 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/4ab5d7809325c8de23956a44ca5a1f3=
c25907faf/src/Hadolint/Rule/DL3018.hs#L20
> This is popping up by default on the most popular editors across the
> world.

I never experienced such behaviour, and I do not agree to it. For
example, pinning versions does not fix security issues.

You could use the tilde operator instead of the equal sign (see
apk-world(5)). But often we fast-forward to a another stable version, which
include bug and security fixes and still behaves the same. So again,
use stable releases and everything should behave the same. That's
our policy and it works pretty good imo!

>
> 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.

This also applies to every other Alpine installation, even containers.
You still have linked libraries in Alpine containers, which WILL break.

For example, I receive a lot of bug reports, because people are using
containers from docker.io/library/docker, which uses Alpine as a base
system. And they install system Python packages. However because Python
fiddles their own python executable with a different version in the
container, most (all?) system python packages will fail.

That's also why we dont allow system pip package installations.

>
> 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

We have a (currently mostly inactive) group which targets bit-per-bit
reproduciblity for Alpine at #alpine-reproducible on OFTC.

>
> > 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