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
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.