Hi, Quoting Helmut Grohne (2024-06-25 10:16:20) > 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.
for those who are interested in the longer story behind all of this, let me
explain this here. Maybe this background helps to give a bit more of a context
about why we were thinking about this. If my memory serves me right, I think
the initial trigger for all of this was an idea that Julian Andres Klode had:
instead of having to manually run
$ mmdebstrap --variant=buildd unstable ~/.cache/sbuild/unstable-arm64.tar
manually before running sbuild for the first time and every once in a while
after that, could the sbuild unshare backend not run this command automatically
if the chroot tarball doesn't exist yet or became too old? If that were the
default, setting up a package builder on a new system would be as simple as
running:
$ sudo apt install sbulid
$ sbuild --chroot-mode=unshare -d unstable my_cool_package
Just install the package, no setup required, and just start building things. So
I wrote this MR:
https://salsa.debian.org/debian/sbuild/-/merge_requests/59
Besides automatically creating the chroot, updating the chroot and setting the
maximum age of the chroot tarball, this MR also allows passing custom options
to mmdebstrap depending on the chroot name. So somebody who wants an ubuntu
buildd chroot could have in their ~/.sbuildrc:
$UNSHARE_MMDEBSTRAP_EXTRA_ARGS = {
"focal" => ["--components=universe,multiverse"]
}
And if you want a custom chroot for the rust packages you build, you could have
(using %d and %a as percent escapes for distribution and architecture):
$UNSHARE_MMDEBSTRAP_EXTRA_ARGS = {
"debcargo-%d-%a" => [--include
ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults"]
}
But the big question now is: should all of this functionality and complexity
live in sbuild? Or should it be moved out of sbuild so that for example the
rust team can just have their custom sbuild chroot script doing all the setup
and customization they require without sbuild carrying that functionality? The
question of how to best allow sbuild to allow an external chroot manager lead
to Timo's idea of just replacing 'schroot' with something else which provides
the interface that sbuild uses to communicate with schroot but then in the back
does its own thing. We have such a thing now and that is Helmut's unschroot.py.
But this is not the only option forward. Another option would be to re-purpose
the sbuild autopkgtest backend for this.
Ultimately, what do we want to achieve? We want to make package building
easier, less tedious and more customizable. We are thinking about what the best
architecture would be to achieve this. We have multiple options:
1. bolt the functionality we want into sbuild as extensions to the unshare
backend or by creating new backends with the desired functionality -- this
is https://salsa.debian.org/debian/sbuild/-/merge_requests/59
2. replace the schroot binary with something else which shares the schroot
interface -- this is unschroot.py
3. move functionality into autopkgtest backends and then make sbuild just a
wrapper around autopkgtest
Choosing one of these three options as the correct software engineering
approach becomes even more tricky when we start thinking of persistence.
Providing a persistent user and mount namespace (for example to be able to use
overlay filesystems on top of a unpacked chroot directory) will be *very*
tricky with the current design of the unshare backend and would probably need
to become its own backend, if choice 1. is the one we want to pursue.
Persistence is also something that would be useful for a backend around qemu.
Currently, there exists sbuild-qemu maintained by Christian Kastner which is
not a new backend but is a convenience wrapper on top of sbuild driving it with
the autopkgtest backend and autopkgtest-virt-qemu as the virt server. It would
be great if building packages inside a qemu vm became easier and option 2 would
allow users to create a backend that starts qemu and then communicates with a
process inside qemu efficiently via an AF_VSOCK. Lastly, persistence is also a
requirement for building packages inside a system container which runs an
actual init process when it spins up.
These last two bits (qemu and system containers) also become a very interesting
topic to think about because in contrast to minimal application containers or a
simple chroot directory, we do not want to build packages directly in them
(because we want to build packages in a minimal setup). So now sbuild would
have to manage 3 environments:
1. the system on the outside
2. the system inside qemu or the system container
3. the system in the minimal build chroot inside the VM
This is also why option 3 from above (autopkgtest) is not an obvious solution
because shoving this understanding into autopkgtest will also be some effort.
Why thinking about how sbuild needs to have an understanding how it can
interact from one of these environments with the next inner environment is
important can be shown by one very simple example: why do we have apt inside
our build chroots? The main reason is: because the schroot interface (and that
is a reason why option 2, unschroot.py is not the fits-all solution) does not
provide a facility to let a tool from the outside (environment 1) work on
inside the chroot (environment 3). The unshare backend has this ability. If
sbuild only were using the unshare backend and we drop the schroot backend, I
could easily allow build chroot containing nothing else than essential,
build-essential and build dependencies.
So, this was a big brain dump. Thank you for getting this far. I've had this in
my head for several weeks now and even though I'm very exciting to see where
Helmut's unschroot.py can take us, I do not yet see one way forward that I am
entirely happy with.
Maybe you can share your thoughts.
Thanks!
cheers, josch
signature.asc
Description: signature
