On Sun, May 12, 2019 at 5:02 AM Phil Perry pperry@elrepo.org wrote:
On 12/05/2019 04:45, Nico Kadel-Garcia wrote:
Good evening:
Even though Fedora still has a default /usr/bin/python, which has admittedly changed to a link to /usr/bin/python3 for recent releases, I see that RHEL 8 has no /usr/bin/python. This is going to break a *lot* SRPM's and older python scripts. It's especially going to mess up old "__python" configuration macros for .spec files.
I'd not realized this when I started testing. Heads up, a *lot* of EPEL .spec files are going to need updates.
Correct, there is no default 'python' in RHEL8 - you have python2 and python3, and you get to decide which you wish to use. This is well documented and there have been a lot of RH articles and blog postings about it. See for example:
https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/
Right. There are many SRPMs in various repositories, especially EPEL and Fedora, that explicitly use '%{__python}' or /usr/bin/python in their .spec files, and many scripts that use "#!/usr/bin/env python". They all have to be updated. Evaluating RHEL 8
And sorry if this makes me seem a bit lame, but I've only just started testing RHEL 8 in force. I've not tried to catch up on all the blogs.
If you are packaging software, you will need to decide if you wish to build against python2, python3 or both (that's going to be fun) and specify that explicitly. For example, we needed to patch the mock SPEC file when porting the latest version of mock from fedora to RHEL8 to explicitly specify python2 and/or python3.
Yeah, I took a shot at building mock before I was pointed to https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/, which is very useful indeed. I also went through a lot of this when I backported awscli to RHEL 6 over at https://github.com/nkadel/awsclirepo . I was just noticing this on RHEL 8 as I tried to port awscli.
I'm sad to say that there are was also a confusing decision to rename some packages such as "platform-python-coverage" instead of the old name "python3-coverage", matching the python2-coverage which still exists. I've no idea why someone specifically chose to violate that naming convention, and it had to be a conscious choice.
The good news is the errors are pretty obvious:
Yeah, I've been running into this with RHEL 6 and CentOS 6 backports and on Fedora 30 where /usr/bin/python points to /usr/bin/python3. The errors are usually obvious, they just take time to fix and resolve. It *does* make me encourage the us of both "with_python2" and "with_python3" as options, so that which modules an SRPM is building can be explicit and help us migrate python2 packages to python3 in parallel, and safely.