Bug#901030: some context

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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 <ijackson@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.