Bug 2009821

Summary: Upgrades broken from gfal2-util to python3-gfal2-util
Product: [Fedora] Fedora EPEL Reporter: Carl Edquist <edquist>
Component: gfal2-utilAssignee: Andrea <andrea.manzi>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel7CC: adev88, andrea.manzi, edquist, markus.falb, michal.simon, mihai.patrascoiu, riehecky
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: gfal2-util-1.6.0-7.el8 gfal2-util-1.6.0-7.fc34 gfal2-util-1.6.0-7.el7 gfal2-util-1.6.0-7.fc35 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-28 18:50:24 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:
Attachments:
Description Flags
Patch for Bugzilla#2009821: Adds "Provides" and "Obsoletes" capabilities to python3-gfal2-util package" none

Description Carl Edquist 2021-10-01 16:59:54 UTC
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.

Comment 1 Carl Edquist 2021-10-05 16:51:10 UTC
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

Comment 2 Mihai Patrascoiu 2021-10-06 08:52:58 UTC
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

Comment 3 Carl Edquist 2021-10-06 16:13:08 UTC
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.

Comment 4 Mihai Patrascoiu 2021-10-07 10:02:21 UTC
Created attachment 1830296 [details]
Patch for Bugzilla#2009821: Adds "Provides" and "Obsoletes" capabilities to python3-gfal2-util package"

Comment 5 Mihai Patrascoiu 2021-10-07 10:02:44 UTC
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

Comment 6 Fedora Update System 2021-10-20 09:09:59 UTC
FEDORA-2021-4b858741bf has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4b858741bf

Comment 7 Fedora Update System 2021-10-20 09:17:25 UTC
FEDORA-2021-43f1ded5a0 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-43f1ded5a0

Comment 8 Fedora Update System 2021-10-20 09:26:08 UTC
FEDORA-EPEL-2021-534766850a has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-534766850a

Comment 9 Fedora Update System 2021-10-20 09:35:44 UTC
FEDORA-EPEL-2021-fffa4d177b has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-fffa4d177b

Comment 10 michal.simon 2021-10-20 09:38:48 UTC
Hi Carl,

I pushed Mihai's patch to testing, could you give it a try?

Thanks,
Michal

Comment 11 Fedora Update System 2021-10-20 18:41:58 UTC
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.

Comment 12 Fedora Update System 2021-10-20 19:42:54 UTC
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.

Comment 13 Fedora Update System 2021-10-20 20:03:45 UTC
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.

Comment 14 Fedora Update System 2021-10-21 02:21:41 UTC
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.

Comment 15 Fedora Update System 2021-10-28 18:50:24 UTC
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.

Comment 16 Fedora Update System 2021-10-28 19:31:18 UTC
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.

Comment 17 Fedora Update System 2021-10-28 19:55:26 UTC
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.

Comment 18 Fedora Update System 2021-10-29 23:09:38 UTC
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.