Bug#852820: Testsuite-Restrictions field is hard to use

[Ian Jackson]

Guillem Jover writes ("Re: Bug#852820: Testsuite-Restrictions field is hard to use"):
> On Fri, 2017-01-27 at 15:58:28 +0000, Ian Jackson wrote:
> > If not interpreted very carefully, this would give a test suite runner
> > the erroneous impression that none of the tests can be run.
> 
> Right, I see what you mean.

Can you please add something to the documentation, sayinng that this
field MUST NOT be used to determine whether a package has any tests
that can be run ?  (Because it cannot be correctly so used.)

> > Also, Iain's stated use case in #847926 does not require anything new
> > in the .dsc and hence Sources.gz.  All that is required to get the
> > full information (debian/tests/control) is to extract the source
> > package.  That extraction of the source package has to be done anyway
> > no matter how the tests will be run.
> 
> OTOH, the same could be said for several of the fields in the .dsc, such
> as Build-Depends, but we still list them because it's more convenient to
> not have to extract the source beforehand.

Build-Depends is not a (perverse) atttempt at a summary of some other
pieces of metadata.

> TBH, I hesitated a bit before adding this, because this percolates
> into many other places. But considered that, while the information
> could be retrieved in other ways, it made life easier for test
> runners. And we can always remove it if it ends up being
> unnecessary/undesirable.

You have permanently assigned the name `Testsuite-Restrictions' for
this unnatural meaning, and you and Iain intend for Iain's software to
start relying on it (so withdrawing it would be troublesomw).
Changing published metadata formats is not so easy, I'm afraid.

> But I certainly agree that this should have probably been discussed
> more widely, which is something I overlooked, sorry about that. And
> agree completely with your two points above. So I'll be adding an
> entry to the FAQ detailing the process to add new information to
> the .dsc file (and probably to the .changes and other interchange
> formats).

Thanks,
Ian.