FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

LinkBack Thread Tools
Old 07-18-2012, 03:47 PM
Toshio Kuratomi
Default clarification: python2 modules allowed to go into python2-foo?

On Wed, Jul 18, 2012 at 11:04:02AM +0200, Thomas Spura wrote:
> Hi,
> 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 [1].
> The current python guidelines [2] 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
> package.


http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28pytho n_modules.29

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:

Case 1)
* 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.

Case 2)
* 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

Case 3)
* 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
targets python2

> 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
> python3,python4,python5,python4711...
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?
> Greetings,
> Tom
> 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.

packaging mailing list
Old 07-18-2012, 04:15 PM
John Dennis
Default clarification: python2 modules allowed to go into python2-foo?

I agree with what Toshio has said. We're wedded to the existing naming
for a host of reasons.

As for the flag day Toshio postulates when we pull a lever and switch
from python2 to python3, this is something that keeps me awake at night
sadly. I know many of the python packages I'm involved with will simply
not work with a python3 interpreter without a significant porting effort
(then there is the issue of backward support for python2 in those same
packages). This is especially relevant to Python modules written in C
(e.g. CPython) of which there are quite a few.

So far the only relief from this dilemma has been the observation that
we've been postponing the day of reckoning because the pain threshold is
so high. In other words I don't have to deal with it today.

All of this is to reinforce the point that anything which might cause
via whatever means python2 code to mistakenly execute in a python3
environment would be disastrous and must be carefully avoided.

John Dennis <jdennis@redhat.com>

Looking to carve out IT costs?

packaging mailing list

Thread Tools

All times are GMT. The time now is 01:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org