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, -- Colin Watson (he/him) [[email protected]]
