From Fedora Project Wiki

Revision as of 20:01, 22 August 2012 by Tomspur (talk | contribs) (use one spec for one python implementation)

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

  • Email: tomspur [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: dublicate 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