Package: dpkg-dev
Version: 1.19.1
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org


Dear maintainer,

From to dsc(5):
  Testsuite-Triggers: package-list
     This  field  declares  the  comma-separated union of all test dependencies
     (Depends fields  in  debian/tests/control  file),  with  all  restrictions
     removed, and OR dependencies flattened (that is, converted to separate AND
     relationships), except for binaries generated by this source  package  and
     meta-dependencies such as @ or @builddeps@.

That says that the special value @builddeps@ is ignored for the purposes
of the generation of this field.

I've come to consider this as a issue, as our testing migration software
is not considering build-dependencies as useful (much less needed)
triggers for the testsuite (aka autopkgtest, for the purposes of this
conversation).

I found @builddeps@ useful in multiple occasions, to avoid duplicating
—potentially for a third(!) time— a list of packages; but the lack of
triggers for those is annoying me, and reducing the usefulness of the
testsuite for testing migration purposes.

A practical example here could be src:limnoria, at the version
2018.09.09-1.  That thing uses @builddeps@ to avoid duplicating packages
that are already listed in Build-Depends and in Recommends, but as a
result, the tests are triggered very very rarely, only for the direct
dependency src:python3-defaults and src:limnoria itself.


Informally talking on IRC revealed the following concerns:
1. duplicating the build-dependencies in the triggers has the potential
   to bloat the Sources index file even more
2. this could be a job better done by the testing migration software, by
   e.g. always triggering tests for changing build-dependencies, like it
   already does for changing direct dependencies
3. it would potentially cause useless test runs for things like changed
   debhelper or other build tools that unlikely would change the
   run-time behaviour of the software

IMHO, concerns 1. and 2. could be taken care of by not expanding
@builddeps@ inside Testsuite-Triggers, but instead having it copied
as-is, and then the testing migration software would expand it while
evaluating the triggers.  This would also avoid needless test runs as
they would happen as proposed in concern 2. if all packages had their
build-dependencies trigger tests (however there is a valid idea here
maybe).  I also don't think concern 3. is valid: the extra resources
used would hardly matter in my opinion.


For what my proposal here is concerned, if @builddeps@ end up expanded
in Testsuite-Triggers, it should be flattened like the rest of the
dependencies listed directly in the Depends field of d/tests/control.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Attachment: signature.asc
Description: PGP signature

Reply via email to