Preliminary RHEL 8 review

I've noticed a few things that may help other people setting up test

1) The RPMs on the installation media are split into two distinct
repositories, "BaseOS" and "AppStream", for no reason I can discern.
This means that if you try, like me, to mount a DVD image and use it
as local yum repo for testing out kickstart setups and mock builds,
you need to address the multiple necessary repositories with the new

2) For Virtualbox, it absolutely needs more than 1 GB of RAM.With only
1 GB, it hands during hte firstboot setups.

3) Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.


Re: Preliminary RHEL 8 review

By Stephen John Smoogen at 05/09/2019 - 17:10

As you say, you will need to update kickstarts to add an additional

Do you mean with using the system-python or using a python module?

Re: Preliminary RHEL 8 review

By Nico Kadel-Garcia at 05/09/2019 - 18:54

On Thu, May 9, 2019 at 5:16 PM Stephen John Smoogen < ... at gmail dot com> wrote:
I mean lots of modules, including pytest and python-setuptools_scm. It
also lacks doxygen.

Thank you for the pointer. I can believe that many such modules are in
a distinct channel. It's certainly not on the installation DVD. The
idea that "Code Ready Linux Builder" would contain various python
modules, but that basic sofrtware building tools like gcc, make, and
rpmbuild are om the basic AppStream channel seems..... well, it seems
contradictory to me. I see that channel mentioned in plans for RHEL 8
at <a href="" title=""></a>.

Is there any plan to support separating out this channel for CentOS? I
hope it will be accessible by default in the base configurations, I
really don't want to have deduce that my Chef configurations that need
to compile small local tools need to also already be subscribed to
such a separate channel.

Re: Preliminary RHEL 8 review

By Stephen John Smoogen at 05/09/2019 - 19:08

I do not know what the plans are for how things will be separated out yet.
As you point out the split of things is rather... chaotic and could be
prone to change upstream. I do not know if anything is pushed to CentOS
which says where things go either.. so it will be later in the
build/test/rc cycle before I think things will be known for sure.

Re: Preliminary RHEL 8 review

By Stephen John Smoogen at 05/09/2019 - 19:16

Oh I was using the mock
<a href="" title=""></a> to build my own
things. The patches in his tree
<a href="" title=""></a> may help you
on your work.

Re: Preliminary RHEL 8 review

By Nico Kadel-Garcia at 05/11/2019 - 15:48

Thank you for this pointer. It's a good list of packages that I'd
hoped would be built into RHEL 8, especially the "codeready-builder"
channel when I heard about it. Barring that I hope will be quickly
available in EPEL for use on both RHEL 8 and CentOS 8. Examples of the
useful tools include mock itself and gpg-distribution-keys.

RHEL 8, and potentially CentOS 8, lack "/usr/bin/

By Nico Kadel-Garcia at 05/11/2019 - 23:45

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.

Nico Kadel-Garcia < ... at gmail dot com>

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Phil Perry at 05/12/2019 - 05:02

On 12/05/2019 04:45, Nico Kadel-Garcia wrote:
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:

<a href="" title=""></a>

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.

The good news is the errors are pretty obvious:

*** ERROR: ambiguous python shebang in /usr/libexec/mock/mock:
#!/usr/bin/python -tt. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/mockchain:
#!/usr/bin/python -tt.

and was easily fixed by explicitly specifying python2 instead of python
in the code segment below:

%setup -q
%if %{use_python2}
for file in py/ py/; do
sed -i 1"s|#!/usr/bin/python3 |#!/usr/bin/python |" $file

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Nico Kadel-Garcia at 05/12/2019 - 05:53

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

Yeah, I took a shot at building mock before I was pointed to
<a href="" title=""></a>, which
is very useful indeed. I also went through a lot of this when I
backported awscli to RHEL 6 over at
<a href="" title=""></a> . 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.

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.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Kevin Fenzi at 05/13/2019 - 14:15

That should not be the case in Fedora as far as I know.

/usr/bin/python in fedora (29+) is owned by the
python-unversioned-command package, which is a subpackage of python2 and
points /usr/bin/python to python2.


Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Nico Kadel-Garcia at 05/13/2019 - 14:28

On Mon, May 13, 2019 at 2:15 PM Kevin Fenzi < ... at scrye dot com> wrote:
You're right! I thought it had been changed, along the switch of so
many packages to use python3 by default. But it's still python2, even
in rawhide.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Stephen John Smoogen at 05/13/2019 - 08:40

platform-python is a minimal python which is meant only for allowing system
packages to run. It will probably not see much updates over the life of
RHEL-8. This is based of off python-3.6
python2.7 which is the 2.7 version of python and I expect will have a
lifetime until RHEL-7 is end of lifed. At that point the module will
probably be ended.
python3.6 which is the 3.6 module and may later be end of lifed and
replaced with python-<major>.<minor> of upstreams choosing.

The errors are mostly obvious. There are a bunch of packages which have
some /usr/bin/python embedded in it and may or may not be found during a
build . [I think in most cases it will be found and error out, but I think
I saw one where the python script was skipped and only showed up when I
used it to build something else.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Nico Kadel-Garcia at 05/13/2019 - 14:07

Begging your pardon, but so what if there are many distinct pythons
available? It this one is the system default python, great. But this
is making various existing tools incompatible, with this and other
"platform" packages. don't break the existing tools, especially Fedora
and backporting work from there to RHEL and CentOS. This renaming
particularly includes the CentOS 7 "extras" packages with "python" in
the name, all 76 of them. It's creating work.

I'm also afraid I don't see where the frequency of updates affects
this. This is partly because I think it's very optimistic to say that
python 3.6 won't get any incremental updates. It's already been
updated once since the original DVD medium was published for RHEL 8.
It's fairly common to do minor updates to tools like this during point

This "rename packages as platform-package" name seems confusing and
unnecessary. If that kind of reference to "platform" versions were
needed, perhaps it should have been published as a metapackage, with
"platform-python" empty except for "Includes: python3". As it is, it
seems merely confusing and in conflict with 20 years of Red Hat
package naming convention.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Jonathan Billings at 05/13/2019 - 15:44

On Mon, May 13, 2019 at 02:07:42PM -0400, Nico Kadel-Garcia wrote:
The idea is that you never use the platform-package python at all.
It's part of the OS, used for internal tools like dnf, and not in the
standard path.

This will stop people from trying to use pip to upgrade the python
modules used to run the package manager and break updates, for

For packages any other package, you'd use the appstream pythons in
your dependencies. Its best you just treat the internal python as a
black box and not something you actually package against.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Nico Kadel-Garcia at 05/14/2019 - 03:46

On Mon, May 13, 2019 at 3:54 PM Jonathan Billings < ... at negate dot org> wrote:
I see your point. I also realize I'm late to the party, and this is
already a done deal.

Unfortunately, they're not reliably distinct from the mainline python.
Packages such as "platform-python-coverage" deposit their contents in
/usr/lib64/python3.6/site-packages/coverage/. They do use
"%python_provide" in their .spec file, so they get a stack of
"Provides: python3dist(coverage)" and similar results. But this is not
backwards compatible to older RHEL releases. And because the name of
these "platform-party" packages does not even match the package name
of the SRPM, well, it gets confusing to cross-index them. It could be
really useful if the SRPM for python-coverage, which provided the
default version of the coverage module, would add this line:

Provides: python%{python3_pkgversion}-coverage

This would be more consistent with the older package naming schemes,
and more backwards compatible. I'd welcome thoughts as to whether this
is a good idea to encourage from our upstream python packages for
these "platform" components.

python3-pip, and platform-party-pip, is even more hilarious. The
actual pip modules are from platform-party-pip. The binaries in
/usr/bin/ are from python3-pip.

That is a distinct issue. I've personally encountered it in full
destructive force. I've personally published.... 300 SRPMs for various
public and private repos? All to avoid just the random update issues
of pip. I used to do that for cpan published perl packages, too. But
that is a very distinct issue. Since "pip-3 install" now puts the
modules in /usr/local/lib/python3.6/, I think that this alternative
and effective solution has already solved most of *that* problem.
Would you agree that it has to do with the default python module
installation locations, and segregating critical system python tools
from looking in those locations rather than in the system default

Except..... there is no "appstream" package for the python3-coverage
module. And trying to build a python3-coverage module shows that it
would conflict with the platform-party-coverage module.

Maybe I found the one really awkward module? It wouldn't be the first
time I found the edge case early in testing.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Stephen John Smoogen at 05/13/2019 - 15:33

It matters because system-python is paired down to what is needed to run
the things BaseOS comes with. It may not support much else... and most of
the pythonX-FOOBAR packages will not be used by it or vice versa.

Again.. I am not disagreeing with you. As far as I can tell, we have to
throw something major out every big release. For the last couple we
completely threw out the init systems (systemV->upstart->systemd) and we
finally stuck that one so naming conventions and sub-packaging are the new
big thing.

Re: RHEL 8, and potentially CentOS 8, lack "/usr/

By Peter Meier at 05/12/2019 - 06:54

Be aware that there is a minimal python installation (called
platform-python) that is used for platfrom/system tools like yum.

But this minimal python installation should not be used for anything
else and thus there will likely be other packages with python{2,3}-*
naming, as the platform-python-coverage will not be usable for the
regular python installations.

At least this is how I understood the split from the blog posts.



Re: Preliminary RHEL 8 review

By Nico Kadel-Garcia at 05/09/2019 - 15:58

On Thu, May 9, 2019 at 3:54 PM Nico Kadel-Garcia < ... at gmail dot com> wrote:
Sorry, got interrupted. That should read "due to multiple python
dependencies for modules not found on the DVD.