| Summary: | python-six-1.3.0-1.fc19 fails to properly upgrade to python-six-1.4.1-0.fc20 using fedup | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mock <mark> | ||||
| Component: | python-six | Assignee: | Bohuslav "Slavek" Kabrda <bkabrda> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 20 | CC: | bkabrda, mriedem | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-12-16 22:21:35 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: | |||||
| Attachments: |
|
||||||
|
Description
mock
2013-12-16 19:08:18 UTC
well, i checked a machine on which i ran fedup --network 20 several days before my laptop and it does not suffer from the older python-six problem. i checked another laptop i ran fedup on several days after the errant laptop and it does not suffer either from the older python-six problem. it would seem that i just happened to update this particular laptop when the python-six update script piece was borked. does that sound correct? my next question: how can i fix this without a clean install? well, i don't know how it had happened, but perhaps my pip install had downloaded the 1.4.1 version into the site-packages directory. so, in the end, i got it fixed by: 1. grabbing the 1.3.0-1.fc19 version from koji 2. removing the 1.4.1-0.fc20 egg version (directory) and the six.py* files from the site-packages directory 3. yum update that seemed to be less confusing to yum, and it upgraded successfully. closing the ticket. Created attachment 868581 [details]
removes six 1.3.0 egg-info before initial install
I hit something similar on RHEL 6.4 x86_64 and ppc64, except I didn't have a python-six-1.3.0 rpm. I was installing python-six-1.4.1 and it installs fine, but at runtime six 1.3.0 is being loaded on the python path and then dependencies fail which require six >= 1.4.1 (think openstack havana+). There was a six 1.3.0 egg-info file on the site-packages path which is a directory, and six 1.4.1 installs egg-info as a file, so there is some conflict there. Given I didn't have pip installed or a python-six-1.3.0 rpm, I have no idea how the six 1.3.0 egg-info directory got on the system. I worked around it by patching the six 1.4.1 rpm spec to remove the six 1.3.0 egg-info directory before the base install of six 1.4.1. I've attached the rpm spec patch. Granted the scriplet could be smarter, but I was in a rush. :) So actually I think I figured out something else that had nothing to do with the patch I posted here, it wouldn't actually fix the issue. We have a system setup where we're installing packages from a yum repo (which is where my python-six-1.4.1 comes from) and then we're later setting up a test environment using pip and as part of that it installs nose version 1.3.0. I found out that there were build artifacts leftover for nose and six 1.3.0 under /tmp/pip-build-root/ so I have a feeling that when nose 1.3.0 was getting installed, it was somehow building six 1.3.0 and putting that in the python path. The six.py file wasn't overwritten but the egg was, and that's what screwed everything up. I'm not aware of any issues reported against nose if that's indeed what's making the six 1.3.0 show up, but the timestamps on my system from when those happened are the right around the same time (seconds apart maybe) so I have to believe it's related and not some problem with rpms. |