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

On Tue, Jan 31, 2017 at 01:59:47PM +0000, Ian Jackson wrote:
>ISTM that your real problem is that you don't have an efficient way to
>access debian/tests/control.  Perhaps the right answer is to provide
>an additional side channel for this information, rather than burdening
>the Sources file.  Many many, non-testing-related, programs need to
>read Sources.  I think the test metadata is rather too rich to express
>compactly.

I found this bug because we have a similar design issue in Debusine 
(buried in a messy discussion about a tangentially-related problem on 
our end - 
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/1863#note_613244) 
and it occurred to me that Testsuite-Restrictions would have been 
helpful for this if it existed.

In our case, we need to know which restrictions exist in order that we 
can dispatch the autopkgtest task to a worker that has the appropriate 
backends available.  But we don't want to unpack the source package in a 
trusted (non-worker) context, because unpacking source packages does not 
have a particularly great security history, as well as potentially being 
expensive.

I agree that we need an efficient way to access either 
debian/tests/control itself, or some better-summarized subset of it 
(perhaps a deb822-style mapping from test names to restrictions).  I'm 
not sure exactly what that representation should be.  While I take your 
point about burdening the Sources file, this is the sort of information 
we need to be able to get at when we don't have much else available.

Thanks,