Bug 1420332
Summary: | Conflicts prevents upgrade from python to python2 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Anton Guda <atu> |
Component: | python2 | Assignee: | Charalampos Stratakis <cstratak> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | 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
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. I'm just guessing now, but doesn't `rpm -Uvh ...` do the upgrades one by one? With dnf, this has been tested and works. # 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. I have no idea why is this happening. Tibbs? (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} That would be against the guidelines. 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. Thanks for some info. By guidelines I meant those: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages I understand those are the relevant guidelines, but why does making the python2 package obsolete any python package older than itself violate those guidelines? 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. It should be fixed now. Please reopen if you see the issue reappearing. |