From Fedora Project Wiki

Revision as of 13:09, 29 June 2020 by Thrnciar (talk | contribs)


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

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