<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved-->

<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved-->

* Email: tomspur [AT] fedoraproject.org

* Email: tomspur [AT] fedoraproject.org

+

+

* Name: [[User:Mrunge| Matthias Runge]]

+

* Email: mrunge [AT] fedoraproject.org

== Current status ==

== Current status ==

Line 27:

Line 30:

* Plain "python" will be the default implementation choosen by the [[SIGs/Python]]

* Plain "python" will be the default implementation choosen by the [[SIGs/Python]]

* Easier change of default Python implementation

* 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

+

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

== Scope ==

Line 37:

Line 40:

* (Build)Requiring of mixed Python implementations MUST be avoided.

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

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

Current status

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

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.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.