On 28.02.2023 04:15, Mattia Rizzolo wrote:
On Mon, Feb 27, 2023 at 06:11:16PM -0800, Vagrant Cascadian wrote:
It also contains forks of some autopkgtest code, last updated in 2017,
if I am reading the git logs correctly. It is apparently no longer
working with current versions of qemu with the qemu backends:
https://bugs.debian.org/1001250
I think it was forked largely to remove Debian-isms in the autopkgtest
code, which looks to be only packaged on Debian derivatives:
https://repology.org/project/autopkgtest/versions
IMHO, basically that's the main problem reprotest has.
I know I talked with some autopkgtest maintainers in the past, and they
told me that they would really like to also get rid of this code they
have.
What we are interested in is the "backend" part of autopkgtest, the one
that has all of that abstraction layer to run whatever comman in
different environments (qemu, lxc, null, chroot, etc). They would also
like to get rid of this, delegating maintenance of those things.
Therefore, I believe the optimal solution would be for somebody to take
charge of that part, and make a pretty library out of it. Now, as for
how this could happen, ...
ISTM that there are actually two jobs that must always be done: one is
the isolation initiation... but the second is that some filesystems must
also have appeared already. (A totally empty filesystem on "boot" is an
interesting state to be able to reach, but also not a very practical
place to move much further from.)
It's also been my practical experience that trying to separate those two
can be a bit tricksy. Or at least, quite tricksy to do and make
_efficient_, if that's any sort of goal. And yet it's important to do
so, because if one has to reimplement the filesystem construction for
each kind of executor (qemu, lxc, chroot, etc) then that's a lot of ugly
code to maintain.
We try to do both of these things in the warpforge project, and I think
successfully, but a key boundary we chose is that we assume bind and/or
overlayfs mounts are always a viable option -- or something that can act
in a roughly equivalent way. That seems to generally be supportable
across many containment paradigms.
Does autopkgtest make a similar choice somewhere? Or does it have some
different philosophy or fundamental API that makes this less of an issue
than I think of it as?
