Description of problem: If an existing gfal2-util is installed, installing the new python3-gfal2-util as a replacement fails, due to file conflicts between the old gfal2-util and the new gfal2-util-scripts. For el7, python2-gfal2-util has Provides/Obsoletes defined for gfal2-util, to allow upgrade. But python3-gfal2-util does not have an Obsoletes for gfal2-util, so yum does not know to replace the old gfal2-util with python3-gfal2-util. I believe adding an "Obsoletes: gfal2-util < 1.6.0" to the python3-gfal2-util package would allow the correct behavior when installing it, while the old gfal2-util package is still installed (yum will replace the old one). Version-Release number of selected component (if applicable): From: gfal2-util 1.5.3-1.el7 To: python3-gfal2-util 1.6.0-6.el7 How reproducible: Always. Steps to Reproduce: 1. Have an existing install of gfal2-util, or else install it with yum install https://archives.fedoraproject.org/pub/archive/epel/7.2020-10-05/x86_64/Packages/g/gfal2-util-1.5.3-1.el7.noarch.rpm 2. Try installing python3-gfal2-util to replace it: yum install python3-gfal2-util Actual results: "Transaction check error", detailing that each script from install of gfal2-util-scripts-1.6.0-6.el7.noarch conflicts with file from package gfal2-util-1.5.3-1.el7.noarch Expected results: The attempt to install the new python3-gfal2-util package should succeed, replacing the existing install of the old gfal2-util package. Additional info: Likewise, for el8, this is the case for both python2- and python3-gfal2-util. In all cases, I believe adding an "Obsoletes: gfal2-util < 1.6.0" to the python[23]-gfal2-util packages would allow the correct behavior when installing them while the old gfal2-util package is still installed.
We ship a package that Requires python3-gfal2-util, and this issue is breaking upgrades for our users who are coming from the old gfal2-util. We could work around this by shipping a shim package which Requires python3-gfal2-util and Obsoletes gfal2-util < 1.6.0, but we'd much rather have the issue addressed upstream in epel. Is this something you guys would be keen on doing in the near-term? (Mostly wondering if we'll need to ship a workaround or if there is hope for waiting on an upstream fix.) Thanks! Carl PS, I tried to add Adding Petr Vokac to the CC list, as it looks like he did the initial packaging separation for python2/python3. But bugzilla won't allow it as it doesn't recognize his email address. (The one listed in the changelog for gfal2-util 1.6.0-1 [1].) [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1831126
Hello, I am one of the gfal2-util upstream developers. Thank you for reporting this! I find it interesting you mention "Likewise, for el8, this is the case for both python2- and python3-gfal2-util." The `python2-gfal2-util` package does provide: ``` Provides: gfal2-util = %{version}-%{release} Obsoletes: gfal2-util < %{version}-%{release} ``` I will look into why that happens, but any pointers would be greatly appreciated. The current version of gfal2-util is now v1.7.0, where the fix will be applied. However, I'll see if a backport can be provided also for v1.6.0. Cheers, Mihai
Hi Mihai, >The `python2-gfal2-util` package does provide ... Ah, ok - i see what's happening now. I had done a: repoquery --whatprovides gfal2-util which returned python2-gfal2-util on el7 but nothing on el8, so i assumed that the idea in el8 was simply to avoid making a default upgrade path to the python2- option. But it looks like the real story is just that the el8 build of gfal2-util does not build the python2- subpackage at all: https://koji.fedoraproject.org/koji/buildinfo?buildID=1831126 So the problem also exists for python3-gfal2-util in el8, it's just that there is no python2-gfal2-util for el8. So i think python3-gfal2-util for both el7 and el8 should get an "Obsoletes: gfal2-util < 1.6.0" (that specific version since it was the first that removed the package), and optionally you might add "Provides: gfal2-util = %{version}-%{release}" for el8, if you want yum updates to upgrade from gfal2-util to python3-gfal2-util automatically. I suppose the Provides should be left out of python3-gfal2-util for el7 though, to prevent confusing yum about the el7 and el8 options.
Created attachment 1830296 [details] Patch for Bugzilla#2009821: Adds "Provides" and "Obsoletes" capabilities to python3-gfal2-util package"
Hello, I've added "Provides: gfal2-util = %{version}-%{release}" to python3-gfal2-util package for all platforms aside from EL7, and "Obsoletes: gfal2-util < %{version}-%{release}" to python3-gfal2-util package on all platforms. This issue has been fixed upstream and released in `v1.7.0-2` (commit 5236a97 [1]). For the Fedora `v1.6.0-6` version, I'm providing the above patch, as we did not start to release the dependencies needed for `v1.7.0` in EPEL. The provided patch should go into `gfal2-util-1.6.0-7` and allow transparent upgrades from `gfal2-util < 1.6.0` Thank you again for reporting this! Cheers, Mihai [1] https://github.com/cern-fts/gfal2-util/commit/5236a97
FEDORA-2021-4b858741bf has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4b858741bf
FEDORA-2021-43f1ded5a0 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-43f1ded5a0
FEDORA-EPEL-2021-534766850a has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-534766850a
FEDORA-EPEL-2021-fffa4d177b has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-fffa4d177b
Hi Carl, I pushed Mihai's patch to testing, could you give it a try? Thanks, Michal
FEDORA-EPEL-2021-fffa4d177b has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-fffa4d177b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-534766850a has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-534766850a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-43f1ded5a0 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-43f1ded5a0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-43f1ded5a0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-4b858741bf has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-4b858741bf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4b858741bf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-fffa4d177b has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-43f1ded5a0 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-534766850a has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-4b858741bf has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.