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
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
- 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