Bug 1420332

Summary: Conflicts prevents upgrade from python to python2
Product: [Fedora] Fedora Reporter: Anton Guda <atu>
Component: python2Assignee: Charalampos Stratakis <cstratak>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: rawhideCC: bkabrda, cstratak, dmalcolm, j, mhroncok, pviktori, rkuska, tomspur, torsava
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: python2-2.7.13-4.fc26 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-17 16:42:03 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 Anton Guda 2017-02-08 13:21:45 UTC
Description of problem:
Upgrade from old python to new python2 failed due to
conflicts in python2-devel.


Version-Release number of selected component (if applicable):
Old:
python-2.7.13-1.fc25.x86_64
New:
python2-2.7.13-2.fc26.x86_64.rpm
python2-devel-2.7.13-2.fc26.x86_64.rpm

How reproducible:
Always.


Steps to Reproduce:
1. Download all essential python2 packages(main,devel,libs,tkinter,tools)
2. Try to rpm -Uvh python2*.rpm

Actual results:
error: Failed dependencies:
python2 < 2.7.13-2.fc26 conflicts with python2-devel-2.7.13-2.fc26.x86_64

Expected results:
Clean upgrade.


Additional info:
It seems that 2.7.13-2.fc26 < 2.7.13-2.fc26.
May be a rpm bug?

Comment 1 Charalampos Stratakis 2017-02-08 21:17:51 UTC
This must be an issue with the Obsolete tags I recently added for the upgrade path, due to renaming python to python2.

They are in the form of:

Obsoletes: python < %{obs}

Where %{obs} has the value of 2.7.12-9 so I presume that python2 will not actually obsolete python of a higher version-release across Fedora releases (in this case we are talking about the upgrade path from F25->F26).

Tried a distro upgrade from F25 to f26 in a test machine and while the upgrade proceeds normally, python2 does not replace python.

Will dig a bit to try to figure out a good approach to that.

Thanks for reporting it.

Comment 2 Miro Hrončok 2017-02-12 06:48:34 UTC
I'm just guessing now, but doesn't `rpm -Uvh ...` do the upgrades one by one?

With dnf, this has been tested and works.

Comment 3 Anton Guda 2017-02-12 09:20:08 UTC
# ls
python2-2.7.13-2.fc26.x86_64.rpm        python2-tkinter-2.7.13-2.fc26.x86_64.rpm
python2-devel-2.7.13-2.fc26.x86_64.rpm  python2-tools-2.7.13-2.fc26.x86_64.rpm
python2-libs-2.7.13-2.fc26.x86_64.rpm

# dnf install *.rpm
Last metadata expiration check: 1 day, 17:48:46 ago on Fri Feb 10 17:24:49 2017 EET.
Error: problem with installed package python-2.7.13-1.fc25.x86_64
  - package python2-devel-2.7.13-2.fc26.x86_64 conflicts with python2 < 2.7.13-2.fc26 provided by python-2.7.13-1.fc25.x86_64
  - package python2-devel-2.7.13-2.fc26.x86_64 conflicts with python2 < 2.7.13-2.fc26 provided by python-2.7.13-1.fc25.x86_64
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages)

-----------
with --allowerasing works, but removes smbios-utils, python-smbios, smbios-utils-python, yum-dellsysid

In general, IMHO rpm must be functional without high-level tools.

Comment 4 Miro Hrončok 2017-02-12 10:27:59 UTC
I have no idea why is this happening. Tibbs?

Comment 5 Charalampos Stratakis 2017-02-13 10:29:17 UTC
(In reply to Miro Hrončok from comment #4)
> I have no idea why is this happening. Tibbs?

The issue here should be that the %{obs} macro is referring to the 2.7.12-9 version-release.

So while it was working so far, when I updated python2 for rawhide as well as python for the stable branches (to 2.7.13) then the macro basically stopped working, as python on the stable branches is of a higher version-release now, making the python package non-replaceable from python2.

So I believe the solution would be to just omit the %{obs} macro and make the package obsolete python =< %{version}-%{release}

Comment 6 Miro Hrončok 2017-02-13 16:59:51 UTC
That would be against the guidelines.

Comment 7 Jason Tibbitts 2017-02-13 17:31:48 UTC
I'm not sure what I can do here.  I don't think I've ever touched the python2 package, and I haven't actually looked at what it's doing when writing this.

But, yeah, you have to be extremely careful with ordering when renaming packages across distro versions.  I don't pretend to understand how dnf will deal with complicated situations involving Obsoletes: but if you want to have a "rolling" obsolete where at any time the rawhide python2 package will obsolete the F25 python package then you need to make sure that the Obsoletes: line in rawhide always includes the current F25 package version.

Note that this is actually not entirely possible in general for any package since you might push an F25 update at a time when you can't even build a rawhide package.  Anyone doing an update to F26 at that time will need to be able to handle that case manually as part of their "welcome to rawhide" experience.  Any expectations to the contrary are simply not founded in reality, though of course package maintainers should do what they can.  The big hammer solution of an unversioned Obsoletes: has other drawbacks which we need to avoid.

However, I'm not entirely sure what exactly Miro believes is against the guidelines.

Comment 8 Miro Hrončok 2017-02-13 19:51:28 UTC
Thanks for some info.

By guidelines I meant those:

https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Comment 9 Jason Tibbitts 2017-02-13 19:56:21 UTC
I understand those are the relevant guidelines, but why does making the python2 package obsolete any python package older than itself violate those guidelines?

Comment 10 Miro Hrončok 2017-02-14 11:50:55 UTC
Ok, maybe it doesn't.

(In reply to Charalampos Stratakis from comment #5)
> So I believe the solution would be to just omit the %{obs} macro and make
> the package obsolete python =< %{version}-%{release}

That should fix the problem then. I'd go with < and make sure the rawhide release is larger.

Comment 11 Charalampos Stratakis 2017-02-17 16:42:03 UTC
It should be fixed now.

Please reopen if you see the issue reappearing.