Separate several subpackages form the python3 packages - a system-python(-libs) that can be required by various tools that consider themselves "system tools".
- Email: email@example.com
- Release notes owner:
- Targeted release: Fedora 24
- Last updated: 2016-02-04
- Tracker bug: <will be assigned by the Wrangler>
python3 package to be split in several more subpackages:
- system-python-libs - a subset of standard Python library considered essential to run "system tools" requiring Python
- system-python - /usr/bin/system-python binary (interpreter) for the tools to be able to run, provides system-python(abi)
- python3-libs brings in the remaining subset of standard Python library and will require system-python-libs, thus packages requiring it (directly or indirectly) will get the entire standard Python library
- python3 still requires python3-libs and provides python(abi)
The term "system tool" in this context means any package where a maintainer wishes to require system-python package instead of python3 package.
Any package requiring "python(abi) = 3.x" (currently all Python modules and apps) will still bring in the entire standard library and thus will not be affected by this change in any way. Since this dependency is automatically generated, macros will be provided to remove it and depend on "system-python(abi) = 3.x" instead.
If a package maintainer wishes to depend on system-python instead of python3 it is their responsibility to cooperate with the maintainers of all the Python dependencies of their package and do the same thing there. For example consider package foo requiring python3-bar; if foo's maintainer wishes to require system-python instead of python3, they must be sure to make sure python3-bar does this as well, otherwise the depednency chain would bring in python3 package anyway.
Benefit to Fedora
system-python(-libs) will be smaller than python3(-libs) and thus it can reduce the size of images where size is critical, such as Fedora Cloud.
Once this change is complete, we can cooperate with maintainers of tools to require system-python instead of python3 and make sure python3 package is not dragged as a dependency on such installations.
- Proposal owners:
- determine what the essential subset of the standard library is (investigate packages that later might become "system tools")
- split the subset into a subpackage system-python-libs
- create system-python binary and package
- invent macros to change the requirement of python-abi
- test if present packages requiring python3 or python-abi = 3.x work
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines:
- introduce a change to Python packaging guidelines for package maintainers to be able to profit from this change (after the implementation is ready)
- Trademark approval: N/A (not needed for this Change)
N/A (not a System Wide Change)
How To Test
They should not notice any change. Later, when packages depend on system-python, user can benefit form a smaller Cloud image and such.
As explained above, other packages can choose to depend on system-python instead of python3 once this change is done. But we do not require them to do so in order to finish this change.
- Contingency mechanism:
- Rollback the change in python3.spec
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? No
Will be in the Python packaging guidelines.