Features/PythonNamingDependingOnImplementation

Python Naming Depending On Implementation

Summary

Rename all packages, which provide packages for a certain Python implementation, to actually contain the Python implementation built for in the name.

This will make it more reasonable for users to install a package $foo for a given Python implementation $impl: It will be named $impl-$foo.

Owner

• Name: Thomas Spura

• Email: tomspur [AT] fedoraproject.org

• Name: Matthias Runge
• Email: mrunge [AT] fedoraproject.org

Current status

• Targeted release: Fedora 19
• Last updated: 2012-08-22
• Percentage of completion: 00%

Detailed Description

Most current Python packages need to be renamed for unifying the naming of the packages and the corresponding bugzilla component to report a bug report agains. Currently, there are cases, where a python3-foo package is sometimes built in the corresponding python-foo (which provides the package $foo for python2). When reporting bugs against the python3 implementation only, the component in bugzilla will be python-foo and not python3-foo, which is inconsistent.

Benefit to Fedora

• Naming and component in bugzilla is in sync
• Plain "python" will be the default implementation choosen by the SIGs/Python
• Easier change of default Python implementation
• Drawback: duplicate work, as you need to do X review requests/updates, when you want to build the same package for X Python implementations

Scope

• Ask FPC to approve the new guidelines:

 * All packages, which build for a given Python implementation MUST have that Python implementation inside of the package name.
   e.g. python3-chardet, boost-pypy1
 * A Python implementation, you are allowed to choose from is: python2, python3, python2-debug, python3-debug pypy1
 * (Build)Requiring of mixed Python implementations MUST be avoided.
 * Wherever "python" or just "py" is in the name of a macro, that will be the default Python implementation, choosen by the Python SIG and CAN CHANGE from release to release. e.g. python_sitearch, py_ver
 * In a $impl-$foo spec file, one MUST ONLY build against THAT Python implementation $impl.
   Exception: Providing bindings in e.g. boost, where it's allowed to build boost-python2 and boost-python3 from one spec file (If given upstream provides building from one tarball.)

• Ask FESCO for bypassing of mass renaming requests like mingw once did.

(Otherwise we might not be able to rename all packages in a timeframe of one release.)

• Add new macros, e.g. python2_sitearch, python2_ver.
• Write rpmlint tests: (MUST = threat as Error, SHOULD = threat as Warning)
  • python2-foo package MUST provide python-foo.
  • Different $impl-foo packages MUST NOT be required.
  • Shebangs MUST match the provided Python implementation.
• Rename current python-foo packages to python2-foo, let them provide python-foo and use the new python2_* macos.
• Build new python package, which contains the /usr/bin/python symlink and the default python_sitearch macros. The current default Python implementation will be CPython2.
• Start review requests for current python3-foo packages, which are built from python2-foo spec files.
• Ask owners of python-foo (Build)Requiring packages to change it to python2-foo or let them choose to go with the default implementation python-foo. In the later case, they will follow the "whatever is default according to the Python SIG" implementation.
• Also rename pypy to pypy1.

How To Test

• Check that python-foo is provided in the current python2-foo package.
• There are no plain python package installed anymore on the system.

User Experience

• There won't be a python-foo package installed anymore.
• When installing new Python packages, users can guess them as $impl-$foo.

Dependencies

• FPC must approve new guidelines.
• FESCO should approve bypassing new review requests.
• rpmlint: Some tests need to be written.
• Possibly all packages, which build a package for a Python implementation.

Contingency Plan

When not all packages are renamed in time, continue for the next release. No reverting is necessary, as the new e.g. python2-foo packages will also provide python-foo, so that dependencies will still work as expected before the change. Only some more inconsistency of the package naming, which will gradually get smaller.

Documentation

TODO: Further depends on feedback from FPC/FESCO, what will be implementet from this proposal.

Release Notes

Same as documentation. TODO

Comments and Discussion

• See Talk:Features/PythonNamingDependingOnImplementation