On 3 May 2016 at 04:25, Tianon Gravi <admwig...@gmail.com> wrote: > On 1 May 2016 at 21:27, Michael Hudson-Doyle > <michael.hud...@canonical.com> wrote: >> 1) If the Depends is entirely auto generated, that doesn't give the >> maintainer anywhere to encode versioned Depends or alternatives. >> 2) At least in principle, you could get different results on different >> architectures thanks to build tags, but -dev packages are _all.debs. > > We could possibly combat this by looking at Build-Depends and stealing > version constraints and alternatives from there if the package we need > included exists in the Build-Depends, right? (Complex, but > theoretically possible?)
Hm, is there actually any case where Depends (or at least golang-*-dev) and Build-Depends would differ? dh_golang could just copy one to the other... It also occurred to me looking at this that my Built-Using computations should really only look at the dependencies of the main packages. (Probably doesn't make much difference in practice though). >> Not so much of a problem, but I'm also a bit unsure whether the >> generated value should include TestImports or just Imports (probably >> just Imports?). > > If we want to have automated "autopkgtests", then it needs to be both > (which should be reasonably harmless). :) Yeah, good point. Cheers, mwh
