On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > On Tue, 25 Jun 2024 at 10:16:20 +0200, Helmut Grohne wrote: > > In this work, limitations with --chroot-mode=unshare became apparent and > > that lead to Johannes, Jochen and me sitting down in Berlin pondering > > ideas on how to improve the situation. That is a longer story, but > > eventually Timo Röhling asked the innocuous question of why we cannot > > just use schroot and make it work with namespaces. > > I have to ask: > > 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. > > 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). > > 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. Yes, please. FWIW, I want to switch ci.d.n from lxc to podman at some point as well.
Attachment:
signature.asc
Description: PGP signature