On Fri, Sep 14, 2018 at 10:39:36PM +0200, Paul Gevers wrote: > Dear all, > > We are nearly there to enable migration being gated by autopkgtest > results. Unfortunately I recently realized (after implementation and > deployment of what I thought would be the solution) that the current > situation is possibly not good enough yet. I'd like to solicit for your > help on determining the way forward. > > This e-mail is basically a follow-up of my earlier e-mail [1] about > needed improvements. Before I start with my real issue, let me note that > needs-recommends is now deprecated (it is still supported, but the docs > and lintian warn against it). So I don't bother about it anymore, except > somebody (me) still has to fix autodep8 to not emit it. > > Let me describe the problem and the current status. The migration > software (britney2) is now taking versioned dependencies, breaks and > conflicts of the binary packages from the source package that wants to > migrate into account when requesting the tests. It will add versioned > dependencies that are not in testing and it will add packages from > unstable when their version in testing is broken by (or conflicts with) > anything needed from unstable (recursively). However, it is not having > enough information to do this well (at least, I fear), because of the > following: > > 1) it only knows the Testsuite-Triggers, but it is missing possible > version information of test dependencies. (Possibly fixable by > dpkg-source, but that will take time to propagate and then the > Testsuite-Trigger field changes syntax and meaning). > > 2) @builddeps@ is not resolved by dpkg-source, so the migration software > doesn't know if build-depends should be evaluated for the list > (currently the migration software doesn't add them). (Possibly "fixable" > by always evaluating them, or possibly fixable by enhancing dpkg-source). > > 3) test dependencies generated by autodep8 are fully unknown to the > migration software. It seems (but I haven't verified properly) that e.g. > with r packages the test dependencies can be versioned as well. maybe debci could cache the actual test dependencies considered for a given package, including expansion @builddeps@ and stuff produced by autodep8, so that britney2 can query that information to calculate its required tests? a simple action plan would be: - make autopkgtst output the "expanded" control file considered for each test - make debci store that data in the database and expose it via the API (exact format TBD) - make britney2 query that API
Attachment:
signature.asc
Description: PGP signature