Open AdamWill opened 4 hours ago
actually, this is already using self._select_obsoleted_by
to do the heavy lifting, so we can probably just use that in the conflict checker too.
also, thinking about it, "Conflicts cannot happen between solvables with the same name, such solvables cannot be installed next to each other." isn't true - we have parallel-installable packages, like kernel. So I guess this check would incorrectly fail to find conflicts between two kernel packages.
Not sure if _select_obsoleted_by
handles that.
Consider this rpmdeplint failure. It finds conflicts between compiler-rt18-18.1.7-3.fc42.x86_64 from the update and compiler-rt-18.1.8-2.fc41.x86_64 from the existing package set, and between clang18-18.1.7-5.fc42.x86_64 from the update and clang-18.1.8-3.fc41.i686 from the existing package set.
These conflicts are not valid, because the update also contains newer builds of compiler-rt and clang - clang-19.1.0-1.fc42 and compiler-rt-19.1.0-1.fc42 , which are subpackages of llvm.
It looks to me like the way
find_conflicts
attempts to filter out cases where this might happen is naive - it only does this:but that does not handle cases like this.
find_repoclosure_problems
starts with a more sophisticated implementation of this:perhaps that should be generalized out from
find_repoclosure_problems
and used by all subtests for which it is appropriate, including rpmdeplint?