Bug#779559: dpkg-source: Add test dependencies to .dsc

[Guillem Jover]

Hi!

On Mon, 2015-03-02 at 11:15:22 +0100, Martin Pitt wrote:
> Package: dpkg
> Version: 1.17.24
> User: autopkgtest-devel at lists.alioth.debian.org
> Usertags: autopkgtest

> A simpler idea would be to make dpkg-source -b add a new
> XS-Autopkgtest-Depends: header, which aggregates all Depends: lines of
> debian/tests/control, possibly filter out '@' (which are a packages'
> own binaries, not reverse dependencies) for cleanliness, and put them
> into the .dsc that way, so that they appear in Sources.gz. That way
> they would always be current.

Heh, that reminds me a bit of
<http://www.hadrons.org/~guillem/debian/docs/test.proposal>.

In any case, yeah, this sounds fine. I've conflicting thoughts about
the field name, on one hand Testsuite-Depends (to match the existing
field) seems nicer and more neutral, on the other it would take over
that field for a specific testsuite implementation, as the Testsuite
field already supports different values, even at the same time.

But then, the test runners will need to parse the specific test case
dependencies, as in this case @ is omitted, so we might as well just
coalesce any other dependencies in the same field. Hmmm. The problem
with this is that, if in the future we require the information to be
distinct, that's pretty hard to detangle. Merging it, is pretty easy
because it can be done at run-time while source packages get rebuilt.

> The obvious downside is that this brings some extra clutter. Right now
> we have some 1300 packages with tests, but their number has grown
> fast. On the other hand, a lot of packages just use "Depends: @", i.
> e. just test-depend on themselves, so for those we don't need to add
> anything. Most just have a few extra dependencies, but I've also seen
> some which depend on 10 packages. But even if we assume 3000 packages
> with actual reverse test dependencies, and one screen line on average
> worth of Depends: (both of which are rather big overestimates), the
> total impact on the Sources index would be +240 kB uncompressed, or
> perhaps 30 kB compressed. Compared to sid's current Sources.gz which
> is 34 MB uncompressed and 7.4 MB xz'ed that by and large gets lost in
> the noise.

Personally I don't see any problem in an increase in Sources, even of
few MiB if it provides useful information. IMO if you are using Sources
indices, you have the resources to deal with compilation, and the
requirements there can be asymmetric WRT binary package installation.

> Adam or I will be happy to work on a patch, but I'd like to discuss
> this first before we start coding.

Perfect. :)

Thanks,
Guillem