Hi Simon et al,

this is a followup on
https://lists.debian.org/Zn1wJTc_A11vn-m4@remnant.pseudorandom.co.uk.

Much of the time when one uses an autopkgtest backends, the user has few
sets of useful backend options / configurations. Examples:

 * When using mmdebstrap-autopkgtest-build-qemu, one has to pass "--boot
   efi" as well as the image file name and often also --ram-size to the
   qemu backend.
 * For autopkgtest-virt-podman, it is common to pass --init=systemd.
 * autopkgtest-virt-ssh is not useful without --hostname and often more
   options are useful.

If one manually invokes the autopkgtest command, there are quite a few
convenience measures for specifying the tests to be run (.dsc /
.changes / source directory / ...), but the backend configuration needs
to be spelled out in detail. I consider this latter aspect inconvenient.

A simple measure is adding custom scripts called
autopkgtest-virt-something that simply execute an actual backend with
those commonly used arguments to ~/bin or ~/.local/bin (something on
$PATH). Such a script can be as simple as:

$ cat ~/bin/autopkgtest-virt-qemusid
#!/bin/sh
exec autopkgtest-virt-qemu --boot=efi --ram-size=8192 --cpus=2 ~/path/to/image "$@"
$

(Courtesy to Simon for providing this idea.)

Another option would be for autopkgtest to provide an internal aliasing
mechanism wherein the backed arguments could be specified in a
configuration file.

In this bug, I am asking for blessing the script-based approach by
documenting it e.g. in man 1 autopkgtest or providing another way to
record backend configuration via some user configurable mnemonic.

Thanks for considering

Helmut

Hi Helmut,

If it already works like that, indeed, go ahead, but see below.

I'm not sure if I fully parse that part, but I also wonder if you
noticed that autopkgtest already support a simple form of configuration
files (and I wonder if Simon knew and/or remembered it when he proposed
the script idea). See "CONFIGURATION FILES" in $(man autopkgtest).

Although, when I read the man page, I think there's something more to
desire there. E.g. "expanded in-place" sounds like it's easy to get
wrong if you want one parameter to deviate/add to the arguments passed
to autopkgtest. Maybe it would be great to enhance/change the behavior,
such that e.g.:
* one can record defaults for all backends in one automatically
   discovered file (such that it doesn't need to be specified).
* store a default backend that's used when no backend is given (such
   that you don't need to specify the backend at all)
* enables it that arguments have ones preferred default values but that
   those can be overruled by command line arguments
In other words, behavior in configurable software we find all over the
place.

Paul