Multirelease effort: Moving to Python 3

[Daniel P. Berrange]

On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
> Hi all,
> as a new Fedora Python maintainer, I have set myself a goal of moving Fedora to Python 3 as a default. This is going to be a multirelease effort that is going to affect lots of Fedora parts. Since we will need to switch default package manager from Yum to DNF (which is supposed to work with Python 3), we will need to wait for that. I've been told that DNF should be default in F22, so that's my target, too. That should also give everyone else plenty of time to work on other essential packages to make this happen.
> 
> Here is my analysis/proposal:
> Before switching, we need to make sure that everything "important" (*) is Python 3 compatible. There are three steps I see in this transition:
> 1) Getting rid of Python 2 in mock minimal buildroot.
> 2) Porting Anaconda to Python 3.
> 3) Making all livecd packages depend on Python 3 by default (and eventually getting rid of Python 2 from livecd) - this will also require switching from Yum to DNF as a default, that is supposed to support Python 3.
> ( 4) Making as much of the remaining packages Python 3 compatible )

If we do any work on python3 conversions, it must be done in the context
of respective upstream projects, and not a Fedora custom addon. It will
also quite likely require non-negligable dev resources to make a big dent
in it. It is unlikely to be as simple as just telling upstream to run 2to3,
because a great many upstreams are going to want to provide ongoing support
for both Python2 and Python3 to satisfy non cutting edge distros.

> From packaging point of view, this will probably require:
> 1) Renaming python package to python2

Renaming this is fine, particularly if we also add a Provides: python

> 2) Renaming python3 package to python

This is a bad idea IMHO. Python3 is not upgrade compatible with functionality
previously provided in the current python package. So such a rename is going
to needlessly cause pain & suffering.

> 3) Switching the %{?with_python3} conditionals in specfiles to %{?with_python2}
> (we will probably create a script to automate this, at least partially)

I don't think we need do any automated conversion of that sort. It is perfectly
reasonable for packages to in fact have both %{with_python3} and %{with_python2}
conditionals present. By all means add  %{with_python2} to allow builds without
the legacy python2 stuff, but no need to blanket remove %{with_python3} - leave
it upto the maintainer to decide if they wish to have conditionals for this, or
unconditionally build both.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|