Future of reprotest and alternatives (sbuild wrapper)?

[Eric Myhre]

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?