Bug 1502458
| Summary: | rpmdeplint fails to find conflict on /usr/share/man/man1/vim.1.gz between vim-common and different version of vim-minimal | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Callaghan <dcallagh> |
| Component: | rpmdeplint | Assignee: | Miroslav Vadkerti <mvadkert> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | djc, fzatlouk, jorris, jpopelka, lalajogaar, mvadkert |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | rpmdeplint-2.0~rc3-1.fc39 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-11-03 18:26:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dan Callaghan
2017-10-16 05:25:03 UTC
The reason rpmdeplint doesn't find this conflict is because of bug 1400722. The solution to that bug was to only check *one* conflict candidate, and then skip the rest to avoid potentially downloading hundreds of GB of debuginfo packages to check against. However in this case, when you test the set of packages from that vim build together, the first conflict candidate is actually vim-minimal from the packages under test. And its contents for /usr/share/man/man1/vim.1.gz match so there is no conflict (that's how vim-minimal and vim-common can coexist on an up-to-date system). When we decided on that approach, our assumption was that if we check the first conflict (assuming it was already in the repositories) and it's okay, then everything else in the repositories should be okay too otherwise the problem would have already been found previously. However the original patch missed the possibility that the first conflict candidate might actually be in the packages under test and therefore we might never check against a package in the repositories. We can keep basically the same approach but instead of checking the first candidate, we can instead ensure that we always check one *remote* candidate from the repositories. We can always check all local candidates because that's cheap, there is nothing to download from the network in that case. https://gerrit.beaker-project.org/5875 I tried backporting this to the 1.x branch but it doesn't work, because the 1.x branch currently does not consider any conflicts with older versions of the packages because of latest_per_arch=True here:
conflicting_packages = hawkey.Query(self._sack).filter(file=filename, latest_per_arch=True)
However, removing that is not straightforward because it interacts badly with how _packages_can_be_installed_together is implemented on this branch. I changed that method in the libsolv commit to make it properly handle all possible situations, whereas the current implementation on 1.x wrongly assumes that any non-conflicting packages can be installed together and thus relies on the latest_per_arch=True instead of doing proper "implicit obsoletes".
I could change _packages_can_be_installed_together on the 1.x branch but I am wary of doing that without introducing further problems.
So I think this will have to just be fixed in 2.0.
Dramacool One of the best platform for Dramas, movies and tv shows in all asian countries like hong kong japanese korean chinese and thailand dramas for free https://dramacool1.cc https://dramacools.sbs Dramacool1.cc is one of the best solution to watch series of all asian dramas and movies full HD. This is the place to watch drama online for free with English subtitles, updated daily. If you are looking for a place to see the latest and hottest drama series and movies, Drama Cool is just the ideal place for you. Website: https://dramacool1.cc FEDORA-2023-a965252f36 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a965252f36 FEDORA-2023-a965252f36 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a965252f36` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a965252f36 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-a965252f36 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. |