On Sun, May 12, 2019 at 5:02 AM Phil Perry <pperry at 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.