Hi, On Tue, 30 Jun 2020 00:15:48 +0200 Ivo De Decker <ivodd@debian.org> wrote:
I didn't close #145257 (and I'm not closing it now), because there are still situations where build-dependencies can be broken:Build-dependencies are (currently) only checked in the excuses step. If src a has a build-dependency on binary b, and the excuse for b is a valid candidate, a will not be blocked. This means a will be able to migrate in the migration stage, even if b isn't able to migrate at that point.Also, if src c has a build-dependency on binary d, and an update of d makes the build-dependency of c unsatisfiable, this will not be detected by britney.
I'm considering to (optionally) generate faux binary packages that reflect the build dependencies such that the second phase of britney2 can properly protect against migration without Build-Depends and equally relevant can also protect against removal of binaries that are still Build-Dependencies in testing to prevent this list: https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html Does anybody see a drawback of handling it that way?
I also realized that test dependencies are in a similar boat, currently we don't track test dependencies in either direction. I'd like to have britney2 track those in a similar way as Build-Depends. A detail that needs to be considered though is that britney2 might lack the complete information to do that correctly: currently it only sees what dpkg puts in the Testsuite-Trigger field and versions are stripped for that purpose and different test stanza's are aggregated so test dependencies don't need to be co-installable.
Paul
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature