On Thu, 23 Jan 2025 at 09:03:02 +0100, Salvatore Bonaccorso wrote:
> Just as a data-point there are actually users, as for the autopkgtests
> run within the pkg-perl group this was enough, so there is
> https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/-/blob/master/examples/check-build?ref_type=heads#L162
> used within the group.
It looks as though that script can be configured to use any autopkgtest
virtualization backend by setting AUTOPKGTEST_VIRT_SERVER and
AUTOPKGTEST_VIRT_SERVER_ARGS.
I would personally suggest podman, which doesn't require root (only a
record in /etc/subuid and /etc/subgid) and has the advantage of being a
tool that is widely used outside the Debian/Ubuntu bubble, using the same
OCI image format as Docker for its container images. There is an EXAMPLES
section in autopkgtest-build-podman(1) and autopkgtest-virt-podman(1)
illustrating how to use it.
Container images for autopkgtest are also suitable for interactive
debugging using podman-run(1). If the contents of the container are
trusted (no security boundary intended between your uid in the container
and your uid on the host), then it can be convenient to use toolbox(1)
from the podman-toolbox package as a replacement for interactive schroot,
with the same convenient sharing of the home directory as schroot.
Or, for sbuild users, the unshare backend autopkgtest-virt-unshare(1)
is a relatively natural choice, since it uses the same mechanisms as
the sbuild unshare backend that is now used on our official buildds, and
also doesn't require root (only a record in /etc/subuid and /etc/subgid,
the same as podman and mmdebstrap). It's Debian-specific, though.
The unshare backend automatically reuses the same tarballs that are used
by sbuild in unshare mode, which is very convenient (although ideally
tests would be run in a separate tarball based on "minbase", to allow
detection of missing dependencies on build-essential packages, which
cannot be detected if the base tarball has those packages preinstalled).
smcv
