On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > Could we use a container framework that is also used outside the Debian > bubble, rather than writing our own from first principles every time, and > ending up with a single-maintainer project being load-bearing for Debian > *again*? I had hoped that after sbuild's history with schroot becoming > unmaintained, and then being revived by a maintainer-of-last-resort who > is one of the same few people who are critical-path for various other > important things, we would recognise that as an anti-pattern that we > should avoid if we can.
Absolutely agreed, strong +1 on this. > At the moment, rootless Podman would seem like the obvious choice. As far > as I'm aware, it has the same user namespaces requirements as the unshare > backends in mmdebstrap, autopkgtest and schroot (user namespaces enabled, > setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in /etc/subgid). I am perhaps a little biased, but I, too, think rootless Podman would be the best for the job :) > Podman uses the same OCI images as Docker, so it can either pull from a > trusted OCI registry, or use images that were built by importing a tarball > generated by e.g. mmdebstrap or sbuild-createchroot. I assume that for > Debian we would want to do the latter, at least initially, to avoid > being forced to either trust an external registry like hub.docker.com > or operate our own. > > Here's the Dockerfile/Containerfile to turn a sysroot tarball into an > OCI image (obviously it can be extended with LABELs and other > customizations, but this is fairly close to minimal): Note that podman run also has --rootfs, that accepts the path to an exploded container, and it supports both idmap and overlayfs on top of it as well. So that's another option, one that skips image management, Dockerfiles etc. entirely, allowing for an even closer experience to the existing tooling. Faidon
