conflict check does not properly leave out existing packages that will be replaced by the update under test

[AdamWill]

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:

        for conflicting in self.pool.solvables_iter():
            # Conflicts cannot happen between solvables with the same name,
            # such solvables cannot be installed next to each other.
            if conflicting.name == solvable.name:
                continue

but that does not handle cases like this.

find_repoclosure_problems starts with a more sophisticated implementation of this:

        # This selection matches packages obsoleted by our packages under test.
        obs_sel = self._select_obsoleted_by(self.solvables)
        # This selection matches packages obsoleted
        # by other existing packages in the repo.
        existing_obs_sel = self._select_obsoleted_by(
            s for s in self.pool.solvables_iter() if s.repo.name != "@commandline"
        )
        obsoleted = obs_sel.solvables() + existing_obs_sel.solvables()
        logger.debug(
            "Excluding the following obsoleted packages:\n%s",
            "\n".join(f"  {s}" for s in obsoleted),
        )

perhaps that should be generalized out from find_repoclosure_problems and used by all subtests for which it is appropriate, including rpmdeplint?

[AdamWill]

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.

[AdamWill]

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.

[AdamWill]

per #21 (comment) , I'm rethinking whether this behavior is actually wrong. It seems like kinda a tricky situation, so I sent a mail out to a few folks and mailing lists to solicit input.