On Wed, May 25, 2022 at 10:09:56PM +0200, Paul Gevers wrote: >... > Chance has it that some Release > Team members have been discussing internally about viewing the key package > set differently already, because there are more potential boundaries to draw > in the current set. (As an example of what I am thinking of, in most cases I > would happily trade a grave bug against an FTBFS bug due to missing > <nocheck> or <nodoc> dependencies (by removing the said grave bug containing > package from testing).
This sounds like a bad idea to me. Then the package cannot easily be built in the release. This screws both derivatives that rebuild our distribution and our security team. Additionally, <nodoc> permits both different package contents and a different set of binary packages to be built (empty -doc packages might not be built). > In the current case, we would have to allow > non-installability for the contrib binary package (which currently needs RT > intervention to enable the removal). Except for this bug in the autoremoval calculation, I do not see why it would be relevant where in main/contrib/non-free the packages are. A buggy key package in non-free is not really different from a buggy key package in main, and the latter is the far more common problem. >... > Paul cu Adrian
