Changes/PythonMacroError

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-30
• 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:

• Changes/No_more_automagic_Python_bytecompilation
• Changes/No_more_automagic_Python_bytecompilation_phase_2
• Changes/No_more_automagic_Python_bytecompilation_phase_3

Now, we can define the macro to an 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

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.