trigger tests for updated reverse test dependencies
Bug #1491145 reported by
Steve Langasek
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
britney |
Fix Released
|
Medium
|
Martin Pitt | ||
dpkg (Debian) |
Fix Released
|
Unknown
|
|||
dpkg (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt |
Bug Description
Tracking down the cause of the php5 stalls, I found that the regression in the php-codecoverage tests was caused not by a regression in php5, which it blocks, but in xdebug, which it did *not* block.
This is because xdebug is a test dependency of php-codecoverage but not a build or runtime dependency of it. As a result, xdebug was allowed to regress the state of php-codecoverage's tests in the release pocket, undetected.
Should we trigger tests for test dependencies as well?
Changed in dpkg (Debian): | |
status: | Unknown → New |
Changed in dpkg (Debian): | |
status: | New → Fix Released |
To post a comment you must log in.
Yes, we absolutely should. This has been on the wish list for a long time, and about half a year ago Adam and I talked to the Debian dpkg maintainers how to implement this efficiently. I'm linking to the dpkg bug.
In short, the plan is to make dpkg-source add the collection of test dependencies to the .dsc so that they will appear in the archive's Sources.gz. Then we can actually do a query like "what are the reverse test dependencies of package X", which isn't possible right now.