Antonio Terceiro writes ("Bug#901030: some context"): > the problem here is that by definition, some types of testbed don't > allow you to test some packages.
Right, but in principle these testbeds could. All that is needed is to install binfmt-misc in the host. I am suggesting that this should be fixed by having the container virt server packages depend on binfmt-misc. > in this specific case, there is just no > way you can reliably test a feature that depends on a kernel feature in > a container. As a general rule, what you say is clearly not true. "Being able to run amd64 binaries" is a kernel feature which is generally available in amd64 containers :-). And many more sophisticated kernel features are containerisable (in the sense that they can be used in the container, even if the host doesn't want to know about it, and even if they require root). But, our whole dependency scheme does not really handle kernel features. binfmt-misc is a helper for accessing a kernel feature - one which is available in containers but not configurable separately from the host. Stepping back a bit: if we don't wnat to make adt-virt-lxc depend on binfmt-misc, we could do something more sophisticated: Define two new DEP-8 test fieldc: Virt-Server-Capability-Depends Virt-Server-Capability-Conflicts These are in Depends field syntax but the referred-to names are not packages but capabilities from the virt server protocol. We provide both, so that test authors have the choice between (i) using Depends, and experiencing unnecessary test skips; (ii) using Conflicts, and expericing spurious test failures. We also define new conventional capability syntaxes: bug-* bug-debianNNNNN for use in Virt-Server-Capability-Conflicts. (-Conflicts should usually be used rather than -Depends, because other virt servers who do not have the bug should not be required to advertise it.) We only need to teach autopkgtest about the field names, and then the affected packages can conspire as follows. Package: something-needing-binfmt Virt-Server-Capability-Conflicts: bug-debian901030 And then adt-virt-lxc can advertise a `capability' bug-debian901030. Indeed, if we want to get clever, adt-virt-lxc can do so if: * binfmt-misc is not installed on the host and * the kernel has not been fixed to support per-container binfmt handling Also, virt servers should gain a runtime option for the administrator to have them advertise capabilities. That way it is not necessary to update the software when a new bug is discovered: the admin can update the config. What do people think ? 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.