Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From
the 8.2 beta:
Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)
Name Stream Profiles Summary
python27 2.7 [d][e] common [d] Python programming
language, version 2.7
python36 3.6 [d][e] build, common [d] Python programming
language, version 3.6
python38 3.8 [d][e] build, common [d] Python programming
language, version 3.8
Currently, %python_pkgversion is set to 3 in
/usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros.
python3-devel is still provided only by python36-devel, so presumably all
EPEL8 python packages will continue to be built against python 3.6. But I
imagine that people will soon be asking for python 3.8 versions of EPEL
packages. How can we provide those? Does this have to be done in some
modular fashion - which seems to come back to the discussion of whether or not
every package has to become its own module or whether to group them together
somehow. Or since both python modules are "default" modules and we can
install both python36-devel and python38-devel at the same time, perhaps we
can define the python3_other* macros again for python38 and just go that way?
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
I'm trying to do a local build of gtkwave for EPEL-8.
A koji scratch build somehow works:
But a local build does not:
$ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
Problem: conflicting requests
- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is
- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is
Adding a repo with a local build of Judy doesn't help; that gets
the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11, which is becoming more and more outdated. Me (and a few other people, judging by bug report participation) would quite like to have a newer version of CMake on their systems.
Now, if I understand correctly, according to the EPEL policies, https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is prohibited to replace packages from the base distribution. It is, however, allowed to replace these packages in modules that are not enabled by default.
Unfortunately, nobody really seems to know how to build modules for EPEL. There is documentation for Fedora: https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However, being not very familiar with modularity, I have no clue which parts of the documentation apply to EPEL, and I could not find EPEL-specific documentations and recommendations. I have seen some threads on this list *discussing* these, but it's hard for me to discern the consensus and best practices from mailing list threads.
Would the Modularity magicians be so kind as to reply with some pointers on how to create modules for EPEL? If that already exists, my apologies, I hope you can direct me to that resource.