Bug 2211019

Submitted a MR to specifically set the python3_pkgversion macro to 3.9 for the dnf case. This doesn't address all the instances that might be susceptible to this type of issue, but it at least resolves the DNF case (which really should be protected if at all possible).

I recommend contacting Python team for guidelines how to use default and alternative Pythons.

While the proposed change looks reasonable, I worry that that the request goes against current RHEL 9 supported use cases. Reading <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.2_release_notes/new-features#BZ-2127923> clearly states that users willing to use an alternative Python have to call it by a full name (/usr/bin/python3.11). That implies that users are not supposed to replace /usr/bin/python3 with their own file. Especially if the file is owned by Red Hat-provided python3 package.

In my opinion a removal of platform-python from RHEL 9 was in intentional change.

> If the alternative replaces /usr/bin/python3, dnf will break.

/usr/bin/python3 in RHEL 9 is part of the python3 RPM package provided by Red Hat. Replacing it with different content is not supported by Red Hat.

Do not ever run `alternatives --install /usr/bin/python3 python3 /usr/bin/python3.11 1 ` as described in the reproducer, it replaces a file owned by an official RPM package with a different one. Same way, the system would break if you run `rm /usr/bin/python3` or `ln -sf /opt/mylibc.so.7 /usr/lib64/libc.so.6`. Neither is supported.

--------

You are right that this worked in RHEL 8, however, this feature was removed from RHEL 9 because it was very problematic and RHEL8-specific -- I can explain this in detail if desired. I am sorry if this causes trouble for support.

--------

Specifically setting the %python3_pkgversion macro to 3.9 for a package is not required nor supported. It may break things. Don't do it. RHEL 9 packages that wish to use Python 3.9 must keep the macro set to the default value (3).

--------

Customers/users who want to redefine the meaning of the "python3" command on RHEL 9 may supply their own symbolic link as /usr/local/bin/python3 or even ~/.local/bin/python3 on user-level.

Before I delve into the aspects mentioned by Miro and Petr, I wanted to acknowledge that we can't reintroduce platform-python. The effort would constitute a mass-rebuild style event in the middle of RHEL 9. That doesn't mean we can't be more defensive in the distribution-critical components.


(In reply to Petr Pisar from comment #2)
> I recommend contacting Python team for guidelines how to use default and
> alternative Pythons.

Yep, that already happened before filing the associated MR. The recommended way of achieving this is via the method described by Miro.


> While the proposed change looks reasonable, I worry that that the request
> goes against current RHEL 9 supported use cases. Reading
> <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/
> html/9.2_release_notes/new-features#BZ-2127923> clearly states that users
> willing to use an alternative Python have to call it by a full name
> (/usr/bin/python3.11). That implies that users are not supposed to replace
> /usr/bin/python3 with their own file. Especially if the file is owned by Red
> Hat-provided python3 package.
> 
> In my opinion a removal of platform-python from RHEL 9 was in intentional
> change.

You are correct Petr that the removal was intentional. I will also say that particular use case was not meant to be covered in that design, it just so happens that it was as a happy accident!


(In reply to Miro Hrončok from comment #4)
> > If the alternative replaces /usr/bin/python3, dnf will break.
> 
> /usr/bin/python3 in RHEL 9 is part of the python3 RPM package provided by
> Red Hat. Replacing it with different content is not supported by Red Hat.
> 
> Do not ever run `alternatives --install /usr/bin/python3 python3
> /usr/bin/python3.11 1 ` as described in the reproducer, it replaces a file
> owned by an official RPM package with a different one. Same way, the system
> would break if you run `rm /usr/bin/python3` or `ln -sf /opt/mylibc.so.7
> /usr/lib64/libc.so.6`. Neither is supported.

Many users rely on changing what the python3 symlink points to, since it makes sense until you discover all the breakage in the distribution-critical components (like the breakage described here).

In other words, the end user sees:

    # ls -l /usr/bin/python3*
    lrwxrwxrwx. 1 root root     9 Dec 12 13:12 /usr/bin/python3 -> python3.9
    -rwxr-xr-x. 1 root root 15448 Feb 17 16:44 /usr/bin/python3.11
    -rwxr-xr-x. 1 root root 15448 Dec 12 13:12 /usr/bin/python3.9

And thinks, "You can have python3.9, or python3.11, and python3 is just a less opinionated identifier. I can just change that symlink from python3.9 to python3.11 and roll things forward." They might even assume that this is a perfectly safe thing to do since the Documentation discusses changing at least the unversioned python symlink using alternatives. A good few pieces lead in the direction that this is a perfectly fine thing to do, only to have DNF and/or other components in the distribution break...

If the above seems like an incorrect statement, I recommend taking a look at the Google results for "python3 symlink".


> --------
> 
> You are right that this worked in RHEL 8, however, this feature was removed
> from RHEL 9 because it was very problematic and RHEL8-specific -- I can
> explain this in detail if desired. I am sorry if this causes trouble for
> support.
> 
> --------
> 
> Specifically setting the %python3_pkgversion macro to 3.9 for a package is
> not required nor supported. It may break things. Don't do it. RHEL 9
> packages that wish to use Python 3.9 must keep the macro set to the default
> value (3).
> 
> --------
> 
> Customers/users who want to redefine the meaning of the "python3" command on
> RHEL 9 may supply their own symbolic link as /usr/local/bin/python3 or even
> ~/.local/bin/python3 on user-level.

Yep, this is the "best" way to do it and I believe that @

... (No idea why Bugzilla submitted my comment in the middle of editing) ...

> --------
> 
> You are right that this worked in RHEL 8, however, this feature was removed
> from RHEL 9 because it was very problematic and RHEL8-specific -- I can
> explain this in detail if desired. I am sorry if this causes trouble for
> support.
> 
> --------
> 
> Specifically setting the %python3_pkgversion macro to 3.9 for a package is
> not required nor supported. It may break things. Don't do it. RHEL 9
> packages that wish to use Python 3.9 must keep the macro set to the default
> value (3).
> 
> --------
> 
> Customers/users who want to redefine the meaning of the "python3" command on
> RHEL 9 may supply their own symbolic link as /usr/local/bin/python3 or even
> ~/.local/bin/python3 on user-level.

Yep, this is the "best" way to do it and I believe that @Tomas Orsava is working on including that reference in the primary documentation set.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6645