Last metadata expiration check: 0:05:00 ago on Tue 22 Jun 2021 12:15:54 CEST.
Error:
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:
platform-python-pip-9.0.3-19.el8.rocky.noarch
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?
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.
/usr/bin/python3.6
platform-python-pip = 9.0.3-19.el8.rocky
python36
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.
/usr/bin/python3.6
platform-python-pip = 9.0.3-19.el8
python36
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:
The checksums weren’t updated when the ISO’s were created - eg: checksums from previous ISO’s.
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
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 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.
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.
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)
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.
