Bug 1479795

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.

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

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

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!

Quote from Raplh Bean in https://bugzilla.redhat.com/show_bug.cgi?id=1187057:


"Yeah, this is not a bug.  You 'sudo pip install'd urllib3 at one point and that is conflicting with rpm.

Please 'sudo pip uninstall urllib3' and then try yum installing again after that."

This worked for me too.