Re: [PATCH v3 0/3] releases: build and run any QEMU release easily!

[Fabiano Rosas <farosas@suse.de>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> This series was inspired by a recent post from Fabiano to provide container
> images for migration tests:
> https://lore.kernel.org/qemu-devel/24d04a1f-344d-4b90-a307-b582dd9a1128@oss.qualcomm.com/T/#m353f119dc1a24fa437dde8a96d1891629e64303c
>
> The idea to be able to build and run any QEMU (past) release with containers was
> in my mind for some time, so I gave it a shot. Finally, it was easier than
> expected to obtain a single dockerfile (with a few hacks) that works over all
> our releases.
>

Good stuff, thanks for this work. I'm just not sure how much of it fits
upstream in the current shape, let's discuss...

You say this was in your mind for a while, could you elaborate a bit on
how you think this could benefit the project?

To be clear, my use-case is simply to produce a few containers for
testing migration on my workstation. Your series can help a lot with
that, but from my point of view, some parts are clearly extra and some
are missing.

Also beware that what you're touching here is both "infrastructure" and
"publishing". This has implications for how people consume the work of
the project. There's a chance that people see this as "official QEMU
containers" and try to use them in all sorts of weird scenarios that we
as a community are not prepared to maintain. You might get some
push-back on that basis.

> The oldest functional distro we can find nowadays is ubuntu 12.04. Because of
> this, the oldest QEMU release we can build is v0.12.0. Previous ones require an
> environment we can't get easily today.
>

I think the ability to go all the way back is very cool, but unless we
want to look at this from a archival or heritage perspective, I'd say
there's a line somewhere to how old we should go. I don't see an
use-case for very old binaries. Even knowing if they still work would
already incur in a maintenance cost.

> Images have the absolute minimal content possible. It's only qemu binaries,
> artifacts (roms, keymap, ...), and libraries. There is no shell or any other
> tool included. As a result, images have a size from 149MB (v0.12.0) to 1.48GB
> (v11.1.2).
>

No shell means the first thing to do if one wants to debug the image is
to rebuild with a shell in. Not sure how frequent it will be, maybe it's
ok like this.

> This series adds 3 pieces:
> - a unique dockerfile to build any QEMU release. User has to provide an explicit
>   Ubuntu version when building a given QEMU version.

This is the tricky part. We'll be carrying code (script+dockerfile) that
only works on master. If we tag today and tomorrow the old distro repo
breaks, we obviously cannot fix it retroactively. So we need to be
careful of where we direct the maintenance effort.

1) I'd suggest first of all to keep the release image entirely separate
from the ubuntu image. Treat release.docker as we treat the other
dockerfiles and update it to work for the current release without
looking at past ones. Have it clone, checkout, build and gather
deps. Allow the configure to be tweaked via parameter in case we need to
disable something in an older build.

The script would then build a distro image (or dockerfile) with the
knowledge that it has about ubuntu depending on the QEMU tag vs. ubuntu
version combination. This would allow us to track the cludges more
precisely instead of "some ancient distro" as the dockerfile currently
says.

This is more of a layering concern and how easy it will be to drop/add
version-specific fixes.

2) I wonder if the usage of apt-get build-dep might be a convenience
trap. In theory, some of the adaptations that are required (such as
tweaking dependencies) have already been done by us when working on that
development window.  If we take the dockerfiles from the git tag, those
changes don't need to be done again and for the issues that didn't exist
at the time, we can map them to the git tag instead of ubuntu version;
(we tend to know more about QEMU releases than ubuntu releases).

Another issue with buid-dep is that it lists _ubuntu package_
dependencies. The distro can change how it builds the package without us
noticing. There is already some work done by lcitool, I imagine that it
would then be duplicated. Or worse(!) be different because build-dep
might be listing way more packages that what we need for the default
build.

This is more of a push towards using existing infra because those pieces
are already looked after for other purposes.

> - A script build_release_container.sh which automatically detects which ubuntu
>   version a given release should be buildable on (based on date). It works
>   great, and the heuristic works for all our versions.
> - a script generate_release_links.sh which creates wrapper scripts automatically
>   using prebuilt images (hosted on my dockerhub).
>

It would be nice if these two could take any hash, instead of just a
tag. This is one of the things that will depend on what you intend to
achieve with this series.

> TLDR:
> $ ./scripts/build_release_container.sh v1.6.1
> $ podman run -it --rm qemu/v1.6.1 qemu-system-arm --version
>
> $ ./script/generate_release_links.sh qemu-time-machine
> $ ./qemu-time-machine/v1.6.1/qemu-system-arm --version
> QEMU emulator version 1.6.1, Copyright (c) 2003-2008 Fabrice Bellard
> $ ./qemu-time-machine/v11.0.0/qemu-system-arm --version
> QEMU emulator version 11.0.0 (v11.0.0)
> Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers
>
> v3
> --
>
> - extend dockerfile to support ubuntu 12.04, and lower older revision we can
>   build from v1.6.1 to v0.12.0.
>
> v2
> --
>
> - fix generate_release_links.sh: was missing userns option for podman
> - dockerfile: cleanup "|| true" and replaced with proper ifs
>
> Pierrick Bouvier (3):
>   tests/docker/dockerfiles: add release.docker
>   scripts: add build_release_container.sh
>   scripts: add generate_release_wrappers.sh
>
>  scripts/build_release_container.sh      | 62 ++++++++++++++++++++
>  scripts/generate_release_wrappers.sh    | 71 +++++++++++++++++++++++
>  tests/docker/dockerfiles/release.docker | 76 +++++++++++++++++++++++++
>  3 files changed, 209 insertions(+)
>  create mode 100755 scripts/build_release_container.sh
>  create mode 100755 scripts/generate_release_wrappers.sh
>  create mode 100644 tests/docker/dockerfiles/release.docker