Proposal: Python 3 in Fedora 13

[Ben Boeckel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David Malcolm wrote:
> On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
>> Could we do something similar to what qt and kdelibs packages 
>> have done? While qt3 was default, the 'qt' package points to 
qt3 
>> and qt4 is an entirely separate package. When qt4 became 
>> default, qt3 was the one with the explicit version on it (and 
>> qt4 still exists, but the default 'qt' is qt4 now). This 
would 
>> mean that python2 packages grow 'Provides: python2-foo = 
>> %{version}-%{release}'. When python3 is the default, then 
have 
>> python point to python3 (and we can drop the 
Provides/Obsoletes 
>> for python3- prefixed packages later if wanted).
>> 
>> My thought process is that I would not like, after python3 is 
>> the default, to still have to put the explicit 3 on there 
>> because python is still python2. Just thinking ahead here.
> 
> Thanks!  If I'm correctly reading your mail, this approach is 
one I did
> think of, but I'm not fond of it.
> 
> I think that anyone dealing with Python is going to have to be 
thinking
> "is this python 2 or python 3" for some years to come, so 
having an
> explicit "python3-" prefix is probably not too painful.
Package names wouldn't change for some time. Guido says 2--3 
years, so python meaning python3 is some time away yet.

> What I think would be painful in your suggestion is the flag 
day where
> we'd change the meaning of "python-" in RPM names.  Currently 
in Fedora
> and EPEL, "python-" implies the system-supplied minor release 
of python
> 2, be it in Fedora (2.6), or in EPEL (2.4).  I worry that 
changing it to
> imply the system-supplied minor release of Python 3 (3.1, or 
3.2/3.3? by
> that point) would be thoroughly confusing, since we'd have to 
update
> everything all at once.  It wouldn't fly within EPEL, since 
the
> pre-existing Enterprise downstreams of Fedora aren't going to 
change
> (far too disruptive).
This is where the 'Provides: python2-foo' kicks in. 'Requires:' 
in other packages would be updated to point to the python2-foo 
Provides for dependency solving. Over time, packages should be 
updated and if some deadline isn't met, start opening bugs, then 
finally using provenpackager when another deadline is hit. Even 
after the change, python3 packages would Provides/Obsoletes 
their old python3- names but would be moved to have the main 
package name be python-. Dependency chains should hold as long 
as the python2- and python3- Requires are used instead of the 
python- ones.

> One middle ground might be to start using "python2-" 
explicitly for
> _new_ packages.  That wouldn't break anything, but could 
easily be
> confusing as well.  I think I prefer keeping things 
consistent.
This would still leave python2 to hold claim to the python- 
prefix and python3- left with the 3 in it. And I am for 
consistency here.

> Perhaps at some point we could cut over "/usr/bin/python" from 
being
> Python 2 to Python 3, but I refer you again to this quote from 
Guido:
> http://mail.python.org/pipermail/python-3000/2008-
March/012421.html
Yes, and after that time, what? Always use python3? I'd like to 
start a transition route worked out now before we start down 
towards python3 so that things aren't rushed later.

> (The other fun thing to do might be to package Unladen 
Swallow.  Not at
> all sure what to call _that_ though!)
Hopefully these changes will get merged some day. A faster 
python is on my list of wants for python (as well as a debugger 
and a valgrind-like tool to see where loose references are being 
kept).

> Dave

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKxUjTAAoJEKaxavVX4C1XuycQANByZEaH5Z0894ajjQKkEaaE
IG35V4n1WBVVR/77UPh5sBtJtRvsYXIGduYDdZZL/cwAq8LXS8Kn0j8yOB8Y0V0z
bU6WzAb6UAyZqxRYVL1DKsELAbzonqSTHr9g1as3bGiEsZchKjKNLM+C+RRGMpGr
mgkWCZyyuCEUzt+fZSaQ11TMat2eWApLyDuNupmSkCIxzG7EI5R8ovYT2jiQ732W
YUfnclY9sU3T/KhRUHsHCDsGsJOJMzt3SfZxrCgKzfdh3C/RuIi7v3u//1szGLk4
eK0XTruPwNrmkd7/kOwkjyFDVI/HnGWwvGnljz2bMfPC9he3qJdmPC03X1a91hTR
M6Bljqd4m52X/IebPx+O4i9oEXByaK+UwYkvliEqUqPXdjYijGogTha0KQP8F1RU
b0LFuPy1/MZ99Vizl++gwIKu5cXRuOu00H+G7sRbb0SnhY8qZUcz8HvgAR141lwY
d34f8jnxCXlu0KorxHhg6qMstD6EoATA0wfPeGwPv8MWB6YD3ar5q8vkLykb6qQ/
VJONpAwNLMGGv03IzC60HG+s0kDlcJkdRjPzs20lj1siKS8N4Oza0FvBFFCcyCA5
G1w3BEzAILv2SbxCs9KRrvdUSjVmjC2HKnmYcT2wlv8Hv8Ec5BsN19i/UaYIAD/1
P5VAEUJafmJPovLw2oR6
=GaN9
-----END PGP SIGNATURE-----