On Wed, Jul 18, 2012 at 11:04:02AM +0200, Thomas Spura wrote:
currently we are discussing, if it makes more sense to provide a
python-ipython package or a python2-ipython package, because we are
restructuring the package structure of ipython anyway right now .
The current python guidelines  don't mention, if new python2
providing modules still must/may/should be in a python-foo package, or
if it would be better to put them directly into an python2-foo
and also the first sentence of the python3 module naming section.
"An rpm with a python prefix or suffix means a python2 rpm so we need
a different prefix to denote python3 packages."
Reasoning for python2-foo:
When /usr/bin/python will provide python3,
It's unclear to me that this is in the cards. It's certainly not going to
happen in the next year. I'd bet that it won't even happen in the next two
years. There's several pieces that can be used to help with that decision:
* Most tools switch over to using python3 by default
* We get to the point where python3 is installed on all standard Fedora installs
* We get to the point where python(2) is not installed on standard installs.
* PEP 394 http://www.python.org/dev/peps/pep-0394/
is updated to recommend
that /usr/bin/python points to /usr/bin/python3
* Fedora follows suit
* Some of the criteria in Case 1 has also been satisfied
* We reach 2015 and upstream python announces that there will be no further
releases of python2
* We *have not* switched python2 code to a different interpreter that
this means, that the normal
python-foo MUST be build with python3 as python needs to refer to the
current default /usr/bin/python --version.
This is not a given. Right now, the python- prefix is defined as applying
to python2. Full stop. I think if we were to switch to /usr/bin/python ==
python3 for Fedora 18, then we'd continue to define python-foo as being for
python2. The reason is that python3 has not become "python" in people's
minds yet. People will still yum install python (rather than the python2
virtual provide) and continue to look for python-foo packages.
Reasoning for python-foo:
The majority of modules providing python modules have a python-foo
structure. So when switching to /usr/bin/python = python3, it would
also make sense to ONLY do that with the main python package, but all
python-foo package still provide python2 modules and when you want to
have python3 modules, you MUST require python3-foo. The drawback is,
that you cannot rely on "The package which is named python-foo will be
build with the default python interpreter."
That is not a given now. I don't think I really like the idea of it in the
future either. If we're going to rename python-foo to python2-foo at some
point in the future, I'd rather we leave python3-foo as python3-foo. Do not
create python-foo Virtual Provides or packages as that just leads to user
confusion at any transition points.
I'd vote for python2-foo for new packages and renaming the old
python-foo packages unless they build for $current supported python
versions (atm: python2 AND python3) at the same time (and python3-foo
for python3 modules etc).
Splitting the package names so that some are python2-foo and some are
python-foo is a bad idea.
* User confusion -- I want to report a bug against "import foo". Do I find
that in bugzillla as python2-foo or python-foo?
* Any package which ships modules needs to install into different
directories for python2 vs python3 so it needs to have two
separate subpackages (whether or not the actual code would run on either)
* Any package which does not ship modules does not need python in the name:
applications like gramps are just "gramps", not python-gramps.
So if we decide to rename the python-* modules to python2-* we should have
a flag day or series of flag days. For instance,
* Fedora 27: All python-* modules are renamed to python2-* with Virtual
Provides of python-*
* Fedora 35: All python2-* modules drop their python-* Virtual Provides
That pythonX-foo package, where X is the
first digit of the default python interpreter MUST provide python-foo.
This will allow us to be ready for
As said above, I'm not for tying an actual name or a virtual provide to the
default python interpreter. I'm also not generally for Provides: python-foo
meaning the value of /usr/bin/python OR the value of yum install python OR
the value of what python version gets installed exclusively if you do
a standard Fedora install.
I would be for renaming all python-* to python2-* at some appropriate time
in the future as a flag day with Virtual Provides of python-foo for
backwards compat at that time. We could have a second flag day at some
point after that to remore (and not replace) the Virtual Provides.
What is your opinion towards this?
P.S.: For the case of ipython, we can still leave it at ipython
without any pythonX- in front of it to avoid this, but it would be
great to have a general guidelines for this and I'm happy to help
renaming old packages/move forward to python4711.
Just a note (for others who might not be as familiar with where the lines
are drawn): I think the deepest we'd want to go in Fedora is one major
number. python2, python3, python4. This is because we port modules forward
to the most recent python version (what we ship in the python/python3
package) within that category. If we had to ship a python3.3-3.3.1 package
for backwards compat for some singular modules, I think we'd want to
consider those as a special case and treat them along the lines of the EPEL
python27 packages (rather than name all of our package python27-foo,
python33-foo). With current upstream versioning standards, we'd never ship
python271-foo packages. The micro level versions are supposed to remain
compatible within the series.