Hi, On 25-05-2022 22:09, Paul Gevers wrote:
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.
Neither the key package script nor the autoremoval script care about components, so I currently don't think the issue lies there.
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).
However, this looks like the path where the issue lies. bin:nvidia-kernel-dkms (non-free, built from src:nvidia-graphics-drivers in non-free) Depends (on amd64 only) on nvidia-firmware-470.103.01 which is Provided by bin:nvidia-kernel-support (built from src:nvidia-graphics-drivers) *and* by bin:nvidia-tesla-470-kernel-dkms (built from src:nvidia-graphics-drivers-tesla-470).
In _calculate_rdeps there's a check if there's a real package that provides the Provides and prefers that over others, in case of virtual provides it takes all of them. I believe that's where it goes wrong, as can be seen above, a key package now becomes the reverse Depends of a non-key package.
There's a couple of ideas:- in the rdeps step, only add non-key packages as we're not going to remove key packages (although the Release Team is contemplating to do that in manually curated cases) - if the source also builds a binary that's serving the Provides, don't add it (as there's always a binary that Provides as long as the source is there, so there's no gain in the check) - if there's more than one provider, don't add the rdep relation as there's a reasonable chance that not all of them are going to be removed at the same time (let's not do this, it sounds fragile).
- during the *use* of the rdeps info, do something smart Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature