>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes:
Helmut> In this work, limitations with --chroot-mode=unshare became
Helmut> apparent and that lead to Johannes, Jochen and me sitting
Helmut> down in Berlin pondering ideas on how to improve the
Helmut> situation. That is a longer story, but eventually Timo
Helmut> Röhling asked the innocuous question of why we cannot just
Helmut> use schroot and make it work with namespaces.
I'll be honest, I think building a new container backend makes no sense
at all.
There's a lot of work that has gone into systemd-nspawn, podman, docker,
crun, runc, and the related ecosystems.
I think an approach that allowed sbuild to actually use a real container
backend would be long-term more maintainable and would allow Debian's
DevOps practices to better align with the rest of the world.
I have some work I've been doing in this space which won't be useful to
you because it is not built on top of sbuild.
(Although I'd be happy to share under LGPL-3 for anyone interested.)
But I find that I disagree with the idea of writing a new container
runtime for sbuild so strongly that I can no longer use sbuild for
Debian work, so I started working on my own package building solution.
I realize that I have not done a good job of being constructive here.
I intended to write some blog posts on this topic, but got sucked into
work and tag2upload.
In terms of constructive feedback:
* I think your intuition that sbuild --chroot=unshare is limiting is
good.
* I would move toward a persistent namespace approach because it is
more similar to broadly used container backends.
* overlayfs/fuse-overlayfs are how the rest of the world is solving
these problems (or snapshots and the like). Directories are kind of a
Debian-specific artifact that I find more and more awward to deal with
as the rest of my work uses containers for CI/CD.
signature.asc
Description: PGP signature
