RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2211019 - [regression] dnf is not using platform-python
Summary: [regression] dnf is not using platform-python
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: dnf
Version: 9.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Eva Mrakova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-05-30 09:33 UTC by Juan Manuel Santos
Modified: 2023-11-07 11:33 UTC (History)
10 users (show)

Fixed In Version: dnf-4.14.0-7.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-07 08:54:41 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/rpms dnf merge_requests 23 0 None opened Spec: Set the python version explicitly to 3.9 2023-05-30 19:10:20 UTC
Red Hat Issue Tracker RHELPLAN-158518 0 None None None 2023-05-30 09:36:35 UTC
Red Hat Product Errata RHBA-2023:6645 0 None None None 2023-11-07 08:54:48 UTC

Description Juan Manuel Santos 2023-05-30 09:33:23 UTC 
Description of problem:
RHEL 9 no longer ships the platform-python package, although /usr/libexec/platform-python is still provided:

[root@fastvm-rhel-9-2-207 ~]# ls -l /usr/libexec/platform-python
lrwxrwxrwx. 1 root root 18 Dec 12 14:12 /usr/libexec/platform-python -> /usr/bin/python3.9

dnf has been packaged using /usr/bin/python3 directly:

[root@fastvm-rhel-9-2-207 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux release 9.2 (Plow)
[root@fastvm-rhel-9-2-207 ~]# head -n1 /usr/bin/dnf
#!/usr/bin/python3

This is a problem if a customer needs to install a different Python version (which we actually ship, e.g. python3.11) alongside an alternative. If the alternative replaces /usr/bin/python3, dnf will break.

This would be alleviated if dnf would use either /usr/libexec/platform-python, or /usr/bin/python3.9 directly.

How reproducible:
Every time

Steps to Reproduce:
1. dnf install -y python3.11
2. alternatives --install /usr/bin/python3 python3 /usr/bin/python3.11 1 
3. dnf --help"

Actual results:
Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in <module>
    from dnf.cli import main
ModuleNotFoundError: No module named 'dnf'

Expected results:
dnf should continue working normally

Additional info:
The customer reporting this cannot use virtualenv on their use case. Whether or not installing an alternative is recommended, if platform-python is still shipped, it should be used  by dnf to prevent breakage as much as possible.

Also, other system tools provided by us that use Python are affected too, e.g.:

[root@fastvm-rhel-9-2-207 ~]# head -n1 /usr/sbin/tuned
#!/usr/bin/python3 -Es
Comment 1 Kyle Walker 2023-05-30 19:10:20 UTC 
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).
Comment 2 Petr Pisar 2023-05-31 08:08:36 UTC 
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.
Comment 4 Miro Hrončok 2023-05-31 08:47:59 UTC 
> 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.
Comment 6 Kyle Walker 2023-05-31 16:26:50 UTC 
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 @
Comment 7 Kyle Walker 2023-05-31 16:28:23 UTC 
... (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.
Comment 20 errata-xmlrpc 2023-11-07 08:54:41 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.