regular python needed for RPM package to install
I'm a DoD contractor trying to install s/w which is a .rpm file. When trying to run the program I get the following message. Failed dependencies:
/usr/bin/python is needed by acas_configure-19.03-1.noarch.
I don't see the regular version of python on RHEL 8.x. When I run python -V i get the command not found, but when I run python2 -V i get Python 2.7.16. Any help on this matter would be greatly appreciated.
Responses
Guru
32260 points
Hi Nathaniel,
RHEL 8 ships with Python 3.6 and 2.7 ... both being provided as modules.
$ sudo dnf module list --enabled | grep python
python27 2.7 [d][e] common [d] Python programming language, version 2.7
python36 3.6 [d][e] common [d], build Python programming language, version 3.6
Select which one you want to use with the alternatives command ... :)
$ python -V
bash: python: command not found...
$ sudo alternatives --config python
There are 3 programs which provide 'python'.
Selection Command
-----------------------------------------------
*+ 1 /usr/libexec/no-python
2 /usr/bin/python3
3 /usr/bin/python2
Enter to keep the current selection[+], or type selection number: 2
$ python -V
Python 3.6.8
Regards,
Christian
Guru
32260 points
Hi Nathaniel,
Some additional information ... default version of python on RHEL 8 is 3.6 - there are only some basic packages of python 2.7
installed. If you want to use (old) python 2.7, you may have to install additional packages. You can check what is installed with :
sudo dnf list installed | grep python ... Bear in mind that python 2 is "on the way out", so better choose python 3. :)
Regards,
Christian
Hi Nathaniel,
I see that Christian has already provided enough information.
If you've set alternatives then running "python -V" should actually shows supported/configured python version. As you've mentioned in your initial statement:
When I run python -V i get the command not found, but when I run python2 -V i get Python 2.7.16.
Please get this configured first ( alternatives --set python /usr/bin/python3) and then run the command "python -V" and it should work. Also, use the "yum" command to install packages so that it would pull the dependencies automatically.
Yes, that is seems to be right. Check with application vendor to see if it is supported or compatible with RHEL8.x release. Also, please post the complete error message that you get when running 'yum install' command. Please remember to add the ~~~ as the header & footer of that message for clear indentation and readability. Otherwise, view the Formatting Help at the bottom right corner of your window to know more about it.
You may run the command "rpm -ivvh" to get debug output to see further about error/warnings when executing the command. Otherwise, this should generally work since /usr/bin/python is symbolic linked to python3. May be that the package is designed in such a way that it is looking out for a binary file /usr/bin/python, which is not there. And the one present now is a symbolic link file. If this is the case, then the application could be a legacy one and may not be compatible with RHEL8. Please check with vendor. Have you tried executing the 'yum install' command? I'm sure this might also show up the same error message.
I would double check and make sure the scanner rpm is compatible with EL8. I haven't checked in almost a year now but last I saw the Nessus download only supported versions 6 and 7.
In Fedora 30, the /usr/bin/python binary is provided by the package python-unversioned-command, and one can always try building this package on RHEL 8 using the Fedora source: python2-2.7.17-1.fc30.src.rpm.
Note that this yield Python 2.7, which is end-of-life. For Python 3.7, use the Fedora 31 source.
Hi Nathaniel, I'm maybe a bit late to the party. I just wanted to mention that the use of Python with RHEL 8 is described in this piece of Red Hat documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/using-python3_configuring-basic-system-settings
Guru
21039 points
IMPORTANT TO ANYONE landing here...
Red Hat backports open-source packages such as python and other software from open-source sources.
Why is this important? Someone may tell you (erroneously) that Red Hat's python is out date and needs to be replaced, and they are likely incorrect, Why??? It's because of "backporting" this link and also this link.
quote from first link:
For example, stories in the press may include phrases such as "upgrade to Apache httpd 2.0.43 to fix the issue," which only takes into account the upstream version number. This can cause confusion as even after installing updated packages from a vendor, it is not likely customers will have the latest upstream version. They will instead have an older upstream version with backported patches applied.
Another example of this besides apache quote above - for example, is the log4j issue. When you look up the CVE for log4j Red Hat Linux is NOT affected because Red Hat had the foresight to not include the vulnerability in THEIR edition of rpms.
So if you use Red Hat's editions of python, (2 or 3), you you are using Red Hat's backported edition of python and you need not install the third-party python rpms.
The issue not exactly clear in many of the replies to this discussion above is whether or not the failed dependencies people are experiencing are because they used third-party of python or not. If someone above (or who finds this discussion) is using third party python instead of Red-Hat provided python, then they have to maintain that separately and maintain it routinely apart from normal patching. They may also introduce more vulnerabilities because Red Hat often mitigates things when they backport the parent open-source packages to Red Hat editions.
Please keep this in mind if the issue with this is third-party python and not Red Hat python.
If you are facing Red Hat Python dependency issues then validate your repositories are purely Red Hat and if this is the scenario - then it is fair to submit a Red Hat case with an sosreport for dependency issues if the python really comes from Red Hat and not a third party. If you are using third-party python, then validate your yum repos and take the traditional steps to diagnose and resolve dependency issues for your third-party software.
Regards,
RJ
Guru
21039 points
If you have a true issue with python provided by Red Hat - open a case with them. Using a Fedora version of python with Red Hat Enterprise Linux is "not optimal" and generally should be avoided except maybe for testing purposes on a non-production system. See my last post above. If someone is having an issue with not-Red-Hat python - and are using non-Red-Hat python (third-party software) then start with the last link I provided in my previous post, and keep "backporting" in mind because that is important to know.
Regards,
RJ