[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Proposal: Python 3 in Fedora 13

On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
> Hash: SHA256
> David Malcolm wrote:
> > "Naming convention" proposal:
> > How does this sound:
> >   - an rpm with a "python-" prefix means a python 2 rpm, of 
> the
> > "default" python 2 minor version (for Fedora this will be the 
> most
> > recent stable upstream minor release, for EPEL it will be the 
> minor
> > release of 2 that came with the distro, so 2.4 for EPEL5)
> > 
> >   - an rpm with a "python3-" prefix means a python 3 rpm, of 
> the
> > "default" python 3 minor version (for Fedora this will be the 
> most
> > recent stable upstream release)
> > 
> >  (we could extend this to have specific minor-releases (e.g. 
> use
> > "python24-" for a python 2.4 stack, in case some brave soul 
> wants to get
> > zope/plone running.  But may be better to try to fix the 
> zope/2.6
> > incompatibility at that point (caveat: haven't looked at the 
> details of
> > the issue).  I don't intend to work on such versions))
> > 
> > What about packages without a "python-" prefix?  Proposal:  If 
> upstream
> > has a naming convention for python2 vs python3, use it.  
> Otherwise, add
> > a "python3-" prefix to make things clear.  I'm not sure about 
> the
> > details here.  Examples?
> >  
> > There have been various discussions upstream about what to 
> call the
> > python 3 binary.  My favorite quote on the subject is from 
> Guido,
> > http://mail.python.org/pipermail/python-3000/2008-
> March/012421.html :
> >> During the next 3 years or so, installing Py3k as the default 
> "python"
> >> will be a deed of utter irresponsibility and is likely to 
> break your
> >> system in subtle ways (both OSX and Linux these days use 
> Python for
> >> certain system tasks). If you *really* want to shoot yourself 
> in the
> >> foot this way, go ahead and explicitly use "make altinstall
> >> bininstall" or link it yourself.
> > 
> > I propose that for Fedora we have "/usr/bin/python3" for the
> > system/default version of python 3 and "/usr/bin/python" for 
> the
> > system/default version of python 2.  Both would be symlinks to 
> a binary
> > with the minor-release embedded in the name 
> ("/usr/bin/python3.1" and
> > "/usr/bin/python/2.6").
> > 
> > As I understand things, this should make us broadly in 
> agreement with
> > upstream; see e.g.:
> > http://mail.python.org/pipermail/python-dev/2009-
> April/088862.html
> > http://mail.python.org/pipermail/python-dev/2009-
> April/088884.html
> 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.

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).

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.

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:

(The other fun thing to do might be to package Unladen Swallow.  Not at
all sure what to call _that_ though!)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]