On 2024-06-25 15:02, 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.
This 100%. The effort put into this is obviously appreciated, but the risks mentioned above ring too true. > 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). As a datapoint, I use rootless podman containers extensively both for autopkgtest and as an sbuild backend (though the latter is affected by #1033352 for which I still need to implement a cleaner workaround). I think the only problem I encountered was a corner case when passing in a device into a container: at some point, autopkgtest runs su which uses the setgroups() syscall, and group permissions get lost. The solution was to setup up the proper gidmaps. I documented my findings here [1]. Though this latter issue shouldn't be a problem on buildds, where devices aren't passed in. Best, Christian [1]: https://salsa.debian.org/rocm-team/community/team-project/-/blob/master/doc/rocm-autopkgtests-in-containers.md?ref_type=heads
