[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: autopkgtest gating migration, nearly there. But ...

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
- 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

Reply to: