On Tue, Nov 07, 2023 at 11:35:28AM +0100, Diederik de Haas wrote: > > I am not sure what you mean with heavy-handed here and why that would be > > an issue. > > Not fully understanding it, it felt like "some tests may be problematic, > let's > disable all them"
Do I understand correctly that this no longer is your understanding? > While I'm now less clueless about this then before, I don't feel comfortable > enough that I would be able to 'defend' the inclusion of the <!nocheck> > annotation, so I won't include that part in the MR I'm working on. Fair enough. I can offer you two ways forward. You may add me as reviewer, so I can do the defending part if it becomes necessary. The correctness of a nocheck build profile can be technically validated. If you locally perform a build with and without nocheck and both produce the same artifacts (the reproducible bit-identical ense), then that's a very strong clue that the dependency wasn't used for building (but maybe used for testing). And since "nocheck" really means disabling all tests, you're right in thus annotating the dependency. > I did add the removal of the 2 B-Ds in that MR, but as it doesn't include all > the items of this bug report, I won't close this bug with those changes. Fine. > Note that (currently?) the valgrand B-D is commented out/disabled in > debian/control, so together that may help with the (original) reason for > filing > this bug? Looking at the original reason always is a good idea. :) And yeah, the referenced bug #870176 has a cycle via valgrind. So while looking into libdrm was motivated by the presence of cycles. The approach was looking for low hanging fruit (i.e. relatively obviously unused dependencies) in packages relevant to cycles. So it's not about a particular dependency here. Helmut
