Bug 1479795 - python2-urllib3 fails when dnf is updating
python2-urllib3 fails when dnf is updating
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: python-urllib3 (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Infrastructure SIG
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-09 08:17 EDT by Moises Bites
Modified: 2018-05-21 08:04 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-11-21 09:16:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Moises Bites 2017-08-09 08:17:48 EDT
Description of problem:
After upgrade Fedora from 25 o 26 version, the python2-urllib3 is not updating from dnf command.

Version-Release number of selected component (if applicable):
1.20-1.fc26

How reproducible:

> sudo dnf update -y --best --allowerasing --refresh
Error unpacking rpm package python2-urllib3-1.20-1.fc26.noarch
erro: a descompactação do arquivo falhou  no arquivo /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname: cpio: rename


> sudo dnf install python2-requests
Error unpacking rpm package python2-urllib3-1.20-1.fc26.noarch
erro: a descompactação do arquivo falhou  no arquivo /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname: cpio: rename
  Instalando          : python-chardet-2.3.0-3.fc26.noarch
Comment 1 Jeremy Cline 2017-08-10 09:57:05 EDT
Hi Moises,

It looks like you used ``sudo pip`` to install some Python packages. You'll need to remove those packages and then dnf reinstall them to get them back to a known state for RPM before you can update.
Comment 2 Michal Bocek 2017-11-21 07:11:44 EST
I've experienced a similar error when trying to update the package regularly using dnf. I ran the command on f27 system, right after the upgrade from f26.

----------------------------------------
$ sudo dnf update python2-urllib3
Running transaction
  Preparing        :                                                                                                          1/1 
  Upgrading        : python2-urllib3-1.22-2.fc27.noarch                                                                       1/2 
Error unpacking rpm package python2-urllib3-1.22-2.fc27.noarch
Error unpacking rpm package python2-urllib3-1.22-2.fc27.noarch
error: unpacking of archive failed on file /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname: cpio: File from package already exists as a directory in system
python2-urllib3-1.22-2.fc27.noarch was supposed to be installed but is not!
  Verifying        : python2-urllib3-1.22-2.fc27.noarch                                                                       1/2 
python2-urllib3-1.20-1.fc26.noarch was supposed to be removed but is not!
  Verifying        : python2-urllib3-1.20-1.fc26.noarch                                                                       2/2 

Failed:
  python2-urllib3.noarch 1.22-2.fc27                                                                                              

Error: Transaction failed
----------------------------------------

Additional info:
The [0] file used to be a directory with version 1.20-1.fc26, but with 1.22-2.fc27 it has changed to a symlink. RPM cannot handle this. To avoid that, follow the instructions here [1].

[0] /usr/lib/python2.7/site-packages/urllib3/packages/ssl_match_hostname
[1] https://fedoraproject.org/wiki/Packaging:Directory_Replacement
Comment 3 Jeremy Cline 2017-11-21 09:16:35 EST
Hi Michal,

The file was not a directory in 1.20-1.fc26[0] nor is it a directory in 1.22-2.fc27[1]. It is a directory in upstream[2] since upstream vendors that package.

You have the upstream package installed. ``sudo pip install`` is _not_ safe and you should not ever do it because it writes to the same directory as RPM. You'll need to get rid of the offending directory and re-install the package.

[0] http://koji.fedoraproject.org/koji/search?terms=python-urllib3-1.20-1.fc26&type=build&match=glob
[1] http://koji.fedoraproject.org/koji/search?terms=python-urllib3-1.22-2.fc27&type=build&match=glob
[2] https://github.com/shazow/urllib3/tree/1.22/urllib3/packages
Comment 4 Douglas Pavey 2018-05-21 08:04:09 EDT
The issue is that as other packages use this, symbolic links are created, that must be removed, along with this directory, before it can be removed and upgraded to the next release.  This has happened to me at least three times in the past year.  It has been my only work around, each time the packages have been updated.  The update process needs to check for symbolic links, and recreate them, if they are truly needed, or the packages that rely on this package should not be creating links.

$ cd /usr/lib/python2.7/site-packages/urllib3/packages/
$ ls -al
total 40
drwxr-xr-x. 4 root root 4096 May 20 14:50 .
drwxr-xr-x. 5 root root 4096 May 20 14:50 ..
drwxr-xr-x. 2 root root   84 Apr  5 15:56 backports
-rw-r--r--. 1 root root   74 Aug  6  2014 __init__.py
-rw-r--r--. 1 root root  325 Apr  5 15:56 __init__.pyc
-rw-r--r--. 1 root root 8935 Aug  6  2014 ordered_dict.py
-rw-r--r--. 1 root root 9868 Apr  5 15:56 ordered_dict.pyc
lrwxrwxrwx. 1 root root   12 May 20 14:50 six.py -> ../../six.py
lrwxrwxrwx. 1 root root   13 May 20 14:50 six.pyc -> ../../six.pyc
lrwxrwxrwx. 1 root root   13 May 20 14:50 six.pyo -> ../../six.pyo
drwxr-xr-x. 2 root root   98 Apr  5 15:56 ssl_match_hostname
lrwxrwxrwx. 1 root root   34 May 20 12:21 ssl_match_hostname;5b019ebe -> ../../backports/ssl_match_hostname
lrwxrwxrwx. 1 root root   34 May 20 12:37 ssl_match_hostname;5b01a43e -> ../../backports/ssl_match_hostname
lrwxrwxrwx. 1 root root   34 May 20 13:09 ssl_match_hostname;5b01abe4 -> ../../backports/ssl_match_hostname
lrwxrwxrwx. 1 root root   34 May 20 14:50 ssl_match_hostname;5b01c368 -> ../../backports/ssl_match_hostname
$ sudo rm -rf ssl_match_hostname*

Now, after removing the links, ssl_match_hostname's contents and directory, yum update will work.

$ sudo yum update python-urllib3.noarch
Resolving Dependencies
--> Running transaction check
---> Package python-urllib3.noarch 0:1.10.2-3.el7 will be updated
---> Package python-urllib3.noarch 0:1.10.2-5.el7 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
========================================================================
 Package           Arch     Version          Repository Size
========================================================================
Updating:
 python-urllib3    noarch   1.10.2-5.el7      base      102 k
Transaction Summary
========================================================================
Upgrade  1 Package
Total download size: 102 k
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for base
python-urllib3-1.10.2-5.el7.noarch.rpm                | 102 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : python-urllib3-1.10.2-5.el7.noarch        1/2
  Cleanup    : python-urllib3-1.10.2-3.el7.noarch        2/2
  Verifying  : python-urllib3-1.10.2-5.el7.noarch        1/2
  Verifying  : python-urllib3-1.10.2-3.el7.noarch        2/2
Updated:
  python-urllib3.noarch 0:1.10.2-5.el7
Complete!

Note You need to log in before you can comment on or make changes to this bug.