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. > See: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_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. -Toshio
Attachment:
pgpYoUGiUW_s9.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
