Revision as of 13:09, 29 June 2020

Make the unversioned %{__python} macro error by default

Summary

The %{__python} RPM macro (currently defined to /usr/bin/python for backwards compatibility reasons) will be defined to raise an error when used. Any derived macros (%{python}, %{python_version}, %{python_sitleib} etc.) will propagate the error. Packagers can redefine the macro to any actual value to suppress the error. This is consistent with RHEL 8 behavior. Using /usr/bin/python in Fedora packages remains forbidden.

Owner

Name: Miro Hrončok
Email: <mhroncok@redhat.com>

Current status

Targeted release: Fedora 33
Last updated: 2020-06-29
FESCo issue: <will be assigned by the Wrangler>
Tracker bug: <will be assigned by the Wrangler>
Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

For years, the unversioned /usr/bin/python Python interpreter MUST not be used when building RPM packages in Fedora. However, for backwards compatibility reasons, the %{__python} macro was defined to /usr/bin/python. As a direct consequence, all derived macros:

%{python}
%{python_version}
%{python_version_nodots}
%{python_sitelib}
%{python_sitearch}
%py_shebang_fix
%py_build variants
%py_install variants

used /usr/bin/python as well, unless redefined to custom value different than /usr/bin/python. Some of the macros unfortunately evaluated to empty string when /usr/bin/python was not installed in the buildroot.

We wanted to define %{__python} to an error previously, but unfortunately, this was not yet possible due to backwards compatibility wrt automagic byte compilation. Hence we have done:

Now, we can define the macro to error by default. Packagers can still define it to any custom value.

We will define the macro as follows:

%__python %{error:attempt to use unversioned python, define %%__python to %{__python2} or %{__python3} explicitly}

This is technically consistent with RHEL 8.

We will also define %{python} to %{__python} (we will drop the current Lua logic that is designed to prevent %{python} usage when %{__python} is /usr/bin/python).

The default behavior will be an error:

$ rpm --eval '%__python'
error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly

$ rpm --eval '%python'
error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly

$ rpm --eval '%python_version'
error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly

$ rpm --eval '%python_sitelib'
error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly

As advised, when redefined, the macros continue to work as currently:

$ rpm --define '__python %__python3' --eval '%python'
/usr/bin/python3

$ rpm --define '__python %__python3' --eval '%python_version'
3.9

Despite the error message not actually promoting this, packagers can even explicitly define the macro to /usr/bin/python to mimic the previous behavior. However this remains forbidden in Fedora.

$ rpm --define '__python /usr/bin/python' --eval '%python'
/usr/bin/python

$ rpm --define '__python /usr/bin/python' --eval '%python_sitelib'
/usr/lib/python3.9/site-packages

Feedback

Benefit to Fedora

More consistent behavior between RHEL and Fedora.
Avoids hard to debug mistakes when /usr/bin/python is not present and macros like %{python_sitelib} are used.
Doing the wrong thing is not the easiest default any more.

Scope

Proposal owners:
- Redefine %__python and %python

Other developers: nothing, AFAIK packages in Fedora already dropped this construct, however when not, packagers will need to define %__python in spec to make it work. We believe the error message is self-explanatory.

Release engineering: no impact

Policies and guidelines: Mostly already exist. The macro definition will need to be updated in the Python guidelines to match reality.

Trademark approval: not needed

Upgrade/compatibility impact

No user impact. Some spec files might start to fail to build with this change, but the error is self-explanatory.

How To Test

See examples in Detailed Description.

User Experience

No user impact. Some spec files might start to fail to build with this change, but the error is self-explanatory.

Dependencies

Changes/No_more_automagic_Python_bytecompilation_phase_3

Contingency Plan

Contingency mechanism: the change owners can revert the changes
Contingency deadline: beta freeze
Blocks release? No
Blocks product? No

Documentation

This page is the documentation. The updated macro list will also serve as documentation.

Release Notes

@@ Line 179: / Line 179: @@
 The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
-* Policies and guidelines: Mostly already exist. The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros macro definition] will need to be updated int he Python guidelines to match reality. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Policies and guidelines: Mostly already exist. The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros macro definition] will need to be updated in the Python guidelines to match reality. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->

Search

Changes/PythonMacroError: Difference between revisions