On Tue, Mar 20, 2018 at 10:51:30AM +0100, Petr Viktorin wrote:
Here is a message I want to post to devel-announce later. Let me
know if you see anything wrong (or would like to take over python2
Intent to orphan Python 2
First a disclaimer: I'm all for moving to python3, so
disagreeing with the general idea, but with the transition plan.
tl;dr: Unless someone steps up to Python 2 after 2020, we need to
start dropping python2 packages now.
I think this is a contentious statement.
"need" is the wrong word.
"One of the ways to prepare for the declared EOS from upsteam is to"
would be more accurate.
And it's just one of the possible ways. Another would be prepare a
conditional in all spec files and simply flip it over before a mass
rebuild for F32 (or whatever).
Python 2.7 will reach end of upstream support on 1st of January,
2020, after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
This is also misleading. Those 3000
packages have different upstreams,
and many of those upstreams will support python2 even after python-eol.
We (rightly) don't have the authority to say "please drop
unneeded python2 subpackages, or let us drop them for you" .
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
The way you propose is essentially a mirror of how python3 support
was introduced. For a long time it was hard to use python3 for anything
serious because there was _always_ one or two more unported dependencies.
It took many years to reach this critical mass where everything
"important" was available. This period was harsh on users, because python3
was nice and shiny but people were unable to switch and unable to
_influence_ this state in any significant way, the way that it is hard
to push the whole ecosystem. The proposed model of nipping python2 support
at the edges is the same thing, in reverse. First some leaf packages
are dropped, and then some somewhat more important packages, and then
suddenly it becomes hard to use python2 for anything "serious", even
though it's still "available". I think that's a bad way to proceed for
our users. Let them have a single moment where python2 support goes away.
Announce this moment at least a year in advance. Let them keep running
the last release before that for as long as they need.
If we want to prepare for the python2-eol, IMHO we should first finish
all the steps that don't impact users: convert our tooling, make sure
python2 is not used in build for anything where python3 can be used,
rename packages, fix provides and requires, update she-bangs, add
conditionals to make dropping python2 support easy. In particular,
let's first finish Changes/Avoid_usr_bin_python_in_RPM_Build .