The first beta for Python 3.7 is out. It will hopefully get into Fedora
soon as python37.
After it comes out of beta, we'll upgrade python3 to it.
The What's New list is at: https://docs.python.org/3.7/whatsnew/3.7.html
One thing that's interesting for packagers is PEP 552: Deterministic
Let me summarize in my own words.
A new opt-in mode for byte-compilation makes .pyc (bytecode cache) files
depend only on the contents of the corresponding source file.
If we use this, it will slow down imports, because the whole source file
would need to be read and hashed in order to verify if a .pyc file is
valid. (Currently, metadata like the modification time and file size is
To speed things up, there's an option, UNCHECKED_HASH, which skips cache
validation entirely. Using this would mean that if you modify a .py
source file installed by RPM, the changes wouldn't take effect (the .py
contents would only be shown in tracebacks).
Modifying installed files in production is extremely bad practice, of
course, but it's quite useful for debugging on throw-away systems. If we
adopt UNCHECKED_HASH, anyone doing it will have to remember to remove
the corresponding .pyc file.
Honestly, I'm not sure we want to use this in Fedora. Is anyone here
into reproducible builds, to make a better argument for this?
EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a lot of packages to work for
First problem: Packaging rules.
Because there could be updates of python versions from 3.4 to 3.6 or
3.8, we wanted to make clear what python was used for any particular
library. This would make it so someone needing python-bottle did not
end up with one packaged with python-3.6 installed on a python-3.4
system. So we wanted the names to be more specific than python3 and
went with naming all the sub packages python34 or python36.
However, this was decided a while ago and it may not be the best
convention to use or one that the current python sig would like us to
use. I would like to get a naming convention cleared up and documented
so when we do a mass rebuild that the packages come out with either a
python3-<foo> or python36-<foo>
Second problem: When to do this update
We had been looking to do this in October, but it may make more sense
to do this in November after Fedora29 has shipped so that people can
help focus on this versus anything F29 related. It also gives us some
lead time to write blogs/magazine items. How does 2018-11-14 sound?
Third problem: Updating and rebuilding packages to work with python36
Below are the list of packages I found which were making
python34-<libraryname> packages currently in EPEL-7. In updating to
python36, I would like to have a combined Virtual Fedora Activity Day
where we work together on IRC. First we would get any scripts ready
and then work with release engineering to change macros in epel-macros
to point to the correct versions of python and any name changes. We
would then do a mass release bump and rebuild all the packages against
python3.6. As problems are found during that day we would make
appropriate changes and fix.
This might take 2 gos.
Stephen J Smoogen.
On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
> We of the core dev community commit to supporting Python releases for
> five years. Releases get eighteen months of active bug fixes, followed
> by three and a half years of security fixes. Python 3.4 turns 5 next
> March--at which point we'll stop supporting it, and I'll retire as 3.4
> release manager.
> My plan is to make one final release on or around its fifth birthday
> containing the last round of security fixes. That's about seven
> months from now.
See also PEP 429 -- Python 3.4 Release Schedule .
We have python34 and python36 in EPEL7. python34 being the "main" one
and python36 the "other" one. The original plan  was that once the
ecosystem is adapted well enough, we can switch what "main" and "other"
is and eventually drop python34, creating room for maybe another python3
release to be the "other" next (python38 maybe?). Originally this was
supposed to happen for each release , but this was later abandoned
due to lack of manpower.
Do we want to ever switch "main" with "other"? The problem here is:
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' |
pkgname | sort | uniq | wc -l
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' |
pkgname | sort | uniq | wc -l
The original idea is that all packages would have the python3_other
macros in them  and all we need is rebuild everything in proper
order, maybe with some bootstrapping. However that never happened and
most of the packages I've seen lack the python3_other bits (no
statistics, just my impression).
Is this something we want? If so, are the packagers willing to adapt
their packages (as much as I'd like to do this, I lack the resources to
hack on 228 packages)?
The Python Maint team in Red Hat is here to help. However the drive
would need to come from the EPEL community, as now we are only guessing
what are the needs here.
I noticed that the test files (/usr/lib64/python3.7/test) for python37
are occupying more than 50% in the package size, when I was cleaning
the files in my local machine.
If we actually do not use the test files, I do not want to include the
files in the python37 package.
Just want to separate the files as python37-test sub package.
Because of just reducing the file size.
How do you think? I want to hear your opinions.
Here is the bugzilla ticket.
Separate the test directory as python37-test
Jun Aruga jaruga(a)redhat.com
Hi, this is about:
We have ~300 bugz open and blocking
Some of them are > 1 week old and hence anyone can go and remove the
mentioned (sub)packages. I've retired the packages that were for
retirement and I will retire more once they are unblocked (needs to go
to compose -> portingdb before the automation recognizes it).
I open more bugs as they are closed (I don't wan to deal with 1000 bugs
Retirement is easy. The problematic part is removing subpackages. I go
and manually choose the packages that appear not to be just simple "py
spec generates py2 and py3 subpackages" combo, but a bit more
complicated, and I leave the "simple" ones alone for now.
I'm theoretically able to remove a simple py2 subpackage in about a
minute, yet it is tedious and after ~20 packages I need to stop (before
I go crazy).
We have something in between 900 and 2000 packages to remove (there are
900 leaves to remove and we may make another 1100 into leaves as we go).
Is anyone willing to look into automating this? Write a spec depython2izer?
This usually means:
- removing python2- and python- BRs
- removing %package -n python2 and it's metadata, description & %files
- removing all %py2_build, %py2_install or their older manual variants
- removing python2 tests from %check
- (sometimes) removing %py3dir or python3 dir pushd/popd dance
- (sometimes) removing with_python3 conditionals as they make no sense
IIRC Zbyszek said at Flock that he might work on that. Is that still
true? If not, shall I draft something?