Control: user qa.debian.org Control: usertag -1 udd.debian.org
Hi Simon, On 19-05-2022 13:58, Paul Gevers wrote:
dkms and nvidia-graphics-drivers-tesla-470 currently have RC bug #1010884triggering autoremovals (it was closed today, so maybe it will cease to berelevant soon).
Turns out that the issue is back due to another RC bug for nvidia-graphics-drivers-tesla-470, but this time there's no two package bug involved.
This seems very wrong. I'm fairly sure base-files doesn't depend on graphics drivers, and in any case the NVIDIA proprietary driver is in non-free, so by policy no package in main can possibly depend on it.
While not having figured out where the bug exactly lies (I mean, which lines of code), I think it's important to note that the src:nvidia-settings (in main) is building a bin:nvidia-settings in contrib. This is allowed by policy, but I think this is another case (apart from the two package bugs) in the autoremoval script that isn't ideally covered. I think we we don't want bin:nvidia-settings to be a key (binary) package, even though we want to allow src:nvidia-settings to be a key (source) package. This would be a new concept in the key package definition. 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). 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).
Currently, all dependencies of binaries built by a source key package are treated as binaries built by key (source) packages. In this case the source of nvidia-alternative becomes a key (source) package too, that is nvidia-graphics-drivers, which even lives in non-free.
I also *suspect* that somewhere there's a "Provides" in play, as otherwise I would have expected nvidia-graphics-drivers-testla-470 to already have be a key package (and thus not removed), but I can't find it yet. "Provides" in the key package calculation is just the first it finds (if it's not already provided by something in the set found so far).
So, unless my hunch about the "Provides" is correct and we can find a better way to determine the Providing key package, to fix this bug I think that we need to implement fixes in several places: 1) the key package algorithm needs to ignore binary packages build for contrib by key source packages when iterating. 2) autoremoval needs to be made aware that it shouldn't remove sources in main if a binary built by it lives in contrib and would otherwise be 3) britney (the migration software) needs to be aware somehow that this non-installability is OK-ish.
On the other hand, I prefer to considering this problem in the bigger picture that ginggs and I are having with the current key package definition and it's use.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
