Unable to install python3-pip

Attempting to install python3-pip, I get this:

Last metadata expiration check: 0:05:00 ago on Tue 22 Jun 2021 12:15:54 CEST.
 Problem: conflicting requests
  - nothing provides platform-python-pip = 9.0.3-19.el8 needed by python3-pip-9.0.3-19.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

yet, installed is:


any ideas how to proceed? I know I can probably force install, but something probably not right with the dependency name perhaps in the package build?

Hi iwalker!

This kind of made me worrying, …and so I tried it myself, without any problems up to now.
But for me python3-pip requires some other stuff:

[root@r8-16-dev ~]# dnf repoquery --requires python3-pip
Last metadata expiration check: 0:04:39 ago on Wed 23 Jun 2021 12:03:30 AM CEST.
platform-python-pip = 9.0.3-19.el8.rocky

This was for me now only a Minimal installation, could it be that you have some kind of special installation?

I did a minimal install from 8.4 iso as I generally always build servers this way - I never use graphical environments for servers. Mine seems to expect the package name without “rocky” in it, as if the dependency wasn’t named correctly in the package for python3-pip.

Also, doing your command, gives me different results:

[root@rocky ~]# dnf repoquery --requires python3-pip
Last metadata expiration check: 21:01:43 ago on Tue 22 Jun 2021 12:15:54 CEST.
platform-python-pip = 9.0.3-19.el8

platform-python-pip without rocky in the name.

As an aside, I figured since this post: Invalid ISO Images I would download the minimal ISO again and check the sum, but as you can see:

Rocky-8.4-x86_64-minimal.iso: FAILED

this could be two things:

  1. The checksums weren’t updated when the ISO’s were created - eg: checksums from previous ISO’s.
  2. Checksum is valid, but ISO is corrupted.

so I could install again obviously from the ISO, but I expect the problem will still be the same. I did download again to make sure it wasn’t a failed download, but I expect it’s rather something else. Perhaps the ISO’s will be re-created shortly and maybe it will resolve my issue, but I can see I guess later once I install again.

A minimal install from the dvd1 ISO which does have a matching checksum still results in the same problem. So there are problems with the dependencies being called for python3-pip as mentioned above. That’s the only conclusion I can come to.

Yeah, it really looks like it is this case again, so that you got an ISO from an old mirror and checked it again the old checksum, But if you get a new ISO download and/or download the pagackes directly, you should get the correct installation packages :thinking:

And I actually did use the latest ISO dvd1 for my tests :slight_smile:

I got the correct iso and correct checksum. I am attempting to install from the rocky repos. Not the dvd since the python3-pip is being pulled from repos as is the dependencies which are messed up.

I will also make a checksum check of my ISO, and try to install directly from the repos again, I really don’t know what’s going right now…
okay, all my ISOs match with the latest checksums, at least something ^^

Okay now I spinned up the latest dvd1 ISO, entered https://dl.rockylinux.org/pub/rocky/8.4/BaseOS/os/ as installation target and finally used the preconfigured mirrorlist, which resulted into using mirrors.xtom.de for appstream and ftp.acc.umu.se for the rest.

Used the correct packages for me :slight_smile: Maybe you want to try to directly set a baseurl, to mitigate getting a bad repo-mirror?

Yep, looks like the mirrors are not up-to-date and so causing problems.

sed -i 's/#baseurl/baseurl/g' /etc/yum.repos.d/*.repo
sed -i 's/mirrorlist=/#mirrorlist=/g' /etc/yum.repos.d/*.repo

enabled the baseurl, so now it’s using the dl.rockylinux.org link, and disabled the mirrorlist since this would still attempt it to bypass otherwise. The only problem with this is it will overload dl.rockylinux.org if everyone was to do this, but at least it provides a workaround until all the mirrors update themselves properly.

1 Like

Okay perfect, good to know where it is coming from!

Could look up which exact mirror it was? Because I know that the guys from Infra can disable such mirrors in the MirrorManager :slight_smile:

I grepped under /var/log but unfortunately no clues as to which mirror.

You can get the current mirror by entering dnf repolist -v.

OK, so undid those changes to try to find out the mirror, and this is at least one that has the issue, not entirely sure if there are others as well:

[root@rocky yum.repos.d]# yum install python3-pip
Warning: failed loading '/etc/yum.repos.d/Rocky-Media.repo', skipping.
Rocky Linux 8 - AppStream                                                                                                     3.7 MB/s | 7.1 MB     00:01    
Rocky Linux 8 - BaseOS                                                                                                        221 kB/s | 2.5 MB     00:11    
Rocky Linux 8 - Extras                                                                                                        489  B/s | 2.7 kB     00:05    
 Problem: conflicting requests
  - nothing provides platform-python-pip = 9.0.3-19.el8 needed by python3-pip-9.0.3-19.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@rocky yum.repos.d]# dnf repolist -v | grep -i url
Warning: failed loading '/etc/yum.repos.d/Rocky-Media.repo', skipping.
Last metadata expiration check: 0:00:17 ago on Fri 25 Jun 2021 08:56:31 CEST.
Repo-baseurl       : https://rocky.fleewy.com/8.4/AppStream/x86_64/os/ (7 more)
Repo-baseurl       : https://ftp.gwdg.de/pub/linux/rocky/8.4/BaseOS/x86_64/os/ (6 more)
Repo-baseurl       : http://ftp.acc.umu.se/mirror/rockylinux.org/8.4/extras/x86_64/os/ (6 more)

This seems to show python3-pip belonging to appstream:

[root@rocky yum.repos.d]# yum info python3-pip
Warning: failed loading '/etc/yum.repos.d/Rocky-Media.repo', skipping.
Last metadata expiration check: 0:00:35 ago on Fri 25 Jun 2021 08:56:31 CEST.
Available Packages
Name         : python3-pip
Version      : 9.0.3
Release      : 19.el8
Architecture : noarch
Size         : 19 k
Source       : python-pip-9.0.3-19.el8.src.rpm
Repository   : appstream
Summary      : A tool for installing and managing Python3 packages
URL          : http://www.pip-installer.org
License      : MIT and Python and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and (ASL 2.0 or BSD)
Description  : pip is a package management system used to install and manage software packages
             : written in Python. Many packages can be found in the Python Package Index
             : (PyPI). pip is a recursive acronym that can stand for either "Pip Installs
             : Packages" or "Pip Installs Python".

so this would mean that the problematic repo is the rocky.fleewy.com one.

Sorry for the late reply…

Here we go! Now I also get the error :partying_face:

I also tested now that it is not one of the other once, I will bring it up to the Infra team, thank you very much for your time! (should be fixed shortly)



i’ve the same issue
did it already fixed?


For me pip installed in ~/.local/bin/ and not in /usr/bin. pip3 and pip3.6 were in /usr/bin. Copied the pip binary from ~/.local/bin to /usr/bin and pip is now working. Issue could have been resolved by monkeying with $PATH as well I assume; but, I thought this was a better solution.

Having not rpm managed files in system locations is crying for trouble and becomes unmanagable pretty easy, I’d consider this bad practice. In most situations when I really needed a newer pip than that provided by rpm I found that creating a virtualenv is a great solution.

However, the original issue is not pip-ish but dnf-ish, so we are drifting off-topic.


I agree with @anemarkus - copying pip like what @WhiskeyTangoFoxtrot did from a user-installed binary system-wide is not the way to do it. That’s just asking for trouble. That is the reason why user-installed goes to /usr/local/bin or ~/local/bin or ~/bin in user’s home directories, so as not to conflict or overwrite or be overwritten by system packages.

What should have been done in that instance, would be to prepend those bin paths to the beginning of the $PATH variable. /usr/local/bin will already be there, and for .bashrc in the user’s home directory could have been edited to prepend ~/bin or ~/local/bin or whatever the path was.

1 Like