Quoting Paul Wise (2019-10-07 03:38:55) > On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote: > > FYI, this is because autopkgtest has an abstraction for multiple > > container/virtualization mechanisms (lxc, lxd, qemu, schroot) > It seems like this abstraction should be split out of the autopkgtest > source and then depended on by autopkgtest. Do any other such > abstraction layers exist? I do not know of any other such abstraction layers but would warmly welcome them not only for the purpose of including them in sbuild. Specifically, currently autopkgtest is limited to providing a read-only layer for certain backends and its upstream has no intention of widening the scope of the software [1]. This means that to upgrade an autopkgtest backend, the user has to apply backend-specific actions which defeats the purpose of having a unified abstraction layer for multiple backends in the form they get used by sbuild. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886332 This is also one of the main reasons why the autopkgtest backend is still marked as experimental by sbuild as other contributors to this thread already noticed: sbuild-update will never be able to upgrade autopkgtest-based backends. :( Thanks! cheers, josch
Attachment:
signature.asc
Description: signature