Antonio Terceiro writes ("Bug#901030: some context"):
> Control: severity -1 wishlist
> Control: tag -1 + wontfix
..
> By the same argument we would need one restriction for every
> kernel-related feature out there. Implementing every type of special
> snow flake configuration in autopkgtest is unsustainable, and will be a
> maintainance nightmare.
>
> Instead, we have isolation-machine that says the test needs to be run on
> a VM, and then one can make the tests depend on the needed packages and
> make any other configuration required in the test scripts
> themselves.
I agree that reproducing every package that might need to be installed
in a container host, as a possible test restriction, is not really
workable.
But OTOH these tests _can_ be run in a container, provided that the
container host has some appropriate support. It would be nice to have
a way to declare that.
One way might be to maybe invent new test header
Container-Depends:
which is to be ignored by non-container runners ? The container
runners could have a passlist of packages they were willing to
install.
Alternatively, another completely different approach: One might view
it as a bug that installing binfmt-misc *inside* the container does
not work. After all, each container might reasonably want a different
configuration, and the paths etc. configured in the kernel via the
kernel binfmt API ought not to need to refer to textually-identical
paths inside and outside the container which must therefore refer to
similar programs.
Of course fixing that in the kernel might be too awkward. But it
would justify taking the following view: we should work around this in
test runners that use containers. Most straightforwardly, add a
dependency on binfmt-misc to the package containing adt-virt-lxc.
Does that make some kind of sense ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
