[EPEL-devel] gfal2-util -> python3-gfal2-util upgrade path
Dear EPEL Devs,
We ran into an issue on el7 attempting to upgrade from gfal2-util to the
python3-gfal2-util replacement.
[TL;DR: it seems python[23]-gfal2-util in el7 & el8 should all have an
"Obsoletes: gfal2-util < 1.6.0", even if without a matching Provides.]
Apparently python2-gfal2-util has Provides/Obsoletes info for replacing
gfal2-util, but the python3- option does not.
So if you have the old[1] gfal2-util package installed, and then try to
yum install python3-gfal2-util, yum will not remove gfal2-util, and so it
will end up with file conflicts between the old gfal2-util and the new
gfal2-util-scripts.
I imagine that epel's intention was to leave the default upgrade path for
gfal2-util to the python2- version, and if that is the case I can
understand that it's better not to include a "Provides: gfal2-util" in the
new python3-gfal2-util.
However, it seems python3-gfal2-util should still have an
"Obsoletes: gfal2-util < 1.6.0", to let yum know that it should remove
the old gfal2-util when python3-gfal2-util is installed. (Rather than
failing due to conflicts.)
Likewise, in the el8 case, there are no Provides/Obsoletes for gfal2-util
in either of the python[23]-gfal2-util packages, and as a result if you
have an old[2] gfal2-util package installed, yum will fail if you try to
install the python2- or python3- replacements.
It makes sense that you want to leave out the Provides (as not to
automatically upgrade to either of the python2- or python3- options), but
it seems the Obsoletes should still be there to make the manual install
possible.
Is this something you would consider tweaking?
Thanks,
Carl
[1]
https://archives.fedoraproject.org/pub/archive/epel/7.2020-10-05/x86_64/P...
[2]
https://archives.fedoraproject.org/pub/archive/epel/8.2.2020-11-04/Everyt...