Description of problem: Fedora's vim package had a long-standing bug where installing vim-common (which is pulled in by install /usr/bin/vim or gvim etc) would fail with a file conflict if you had a different version of vim-minimal already installed. (Bug 1066983, bug 1329015, bug 1339713, and about a million other dupes... finally fixed in bug 1487175). Like this: $ sudo dnf upgrade vim Last metadata expiration check: 2:21:33 ago on Mon Oct 16 11:59:09 2017. Dependencies resolved. ============================================================================================== Package Arch Version Repository Size ============================================================================================== Upgrading: vim-X11 x86_64 2:8.0.1030-1.fc25 updates 1.4 M vim-common x86_64 2:8.0.1030-1.fc25 updates 6.7 M vim-enhanced x86_64 2:8.0.1030-1.fc25 updates 1.3 M Transaction Summary ============================================================================================== Upgrade 3 Packages Total size: 9.4 M Is this ok [y/N]: y Downloading Packages: [SKIPPED] vim-enhanced-8.0.1030-1.fc25.x86_64.rpm: Already downloaded [SKIPPED] vim-common-8.0.1030-1.fc25.x86_64.rpm: Already downloaded [SKIPPED] vim-X11-8.0.1030-1.fc25.x86_64.rpm: Already downloaded Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction check error: file /usr/share/man/man1/vim.1.gz from install of vim-common-2:8.0.1030-1.fc25.x86_64 conflicts with file from package vim-minimal-2:8.0.823-1.fc25.x86_64 It sounds like a weird edge case but it's actually not, because vim-minimal is in the minimal install and on all the cloud images. So assuming you started from some slightly out of date install media, and then tried "dnf install vim" because you wanted a real editor, it would fail with an error similar to the above. The "solution" offered for quite a few years was to just explicitly upgrade vim-minimal first to a matching version, although the conflict message gave little hint that that would be a valid solution. The real solution (in bug 1487175) was to add a Conflicts in vim-common for older versions of vim-minimal, so that yum/dnf would know it had to upgrade vim-minimal. For all the years that this was broken (missing the explicit Conflicts) rpmdeplint *could* have been finding this problem. But it doesn't catch it. Version-Release number of selected component (if applicable): 1.3 How reproducible: somewhat easily Steps to Reproduce: 1. Download packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=822026 2. Run rpmdeplint against F25 release repo, for example: rpmdeplint check-conflicts --repo fedora,http://download.fedoraproject.org/pub/fedora/linux/releases/25/Everything/x86_64/os/ vim*-8.0.118-1.fc25.x86_64.rpm (Note that if you test a newer build of vim against Fedora 25 released repos, it may ignore the conflicts because of unsatisfied dependencies for Perl stuff. And if you run the test with Fedora 25 *updates* repo enabled, it will not find any conflict because newer vim is already present.) Actual results: No problems found Expected results: An error about undeclared file conflicts
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.