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

    From Colin Watson@21:1/5 to Ian Jackson on Fri May 30 12:10:01 2025
    XPost: linux.debian.maint.dpkg

    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) [cjwatson@debian.org]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)