FYI—
The story about python shebangs in rhel8 and centos stream 8 is complicated.
Short answer: the shebangs on rhel8 are probably wrong now (even in downstream) and even once they're fixed, cephadm (and other python apps in ceph) from rhel8 builds won't ever be suitable to use on other platforms.
The longer answer seems to be that someone needs to decide what version of python is the correct one on rhel8. Note that when I look at my vanilla rhel8 and stream8 boxes the answer seems to be python3.6.
---------- Forwarded message ---------
From: Miro Hrončok <mhroncok@xxxxxxxxxx>
Date: Sun, May 21, 2023 at 4:26 AM
Subject: Re: question about python shebangs in rhel8 and rhel9
To: Kaleb Keithley <kkeithle@xxxxxxxxxx>, Tomas Orsava <torsava@xxxxxxxxxx>
From: Miro Hrončok <mhroncok@xxxxxxxxxx>
Date: Sun, May 21, 2023 at 4:26 AM
Subject: Re: question about python shebangs in rhel8 and rhel9
To: Kaleb Keithley <kkeithle@xxxxxxxxxx>, Tomas Orsava <torsava@xxxxxxxxxx>
On 20. 05. 23 14:53, Kaleb Keithley wrote:
> Hi,
Hello Kaleb and sorry for making this so complex. It was coerced.
> I'm trying to understand—
>
> Starting with Fedora and Debian packaging guidelines that say the shebang
> should/must be #!/usr/bin/python3.
>
> I maintain a handful of packages in Fedora and CentOS (Storage) SIG that have
> python, and delta any python files that have escaped my notice, the python
> files all do have "correct" shebangs in the source.
>
> I do know about the brp_mangle_shebangs in rpmbuilds.
>
> But I just discovered that on rhel8 and centos stream 8 that the shebangs are
> being mangled to /usr/libexec/platform-python. (Compared to fedora and stream 9
> where they remain [unmangled] as /usr/bin/python3.)
>
> And AFAICT this comes from the "%__python3 /usr/libexec/platform-python" line
> in /usr/lib/rpm/macros.d/macros.python3
Correct.
> (If I understand things, platform-python is there to ensure that a known
> version of python can be found when the end user installs later python from
> AppStream or CRB.)
Actually, when they don't install Python 3.6. Presence or absence of other
versions is meaningless in this context, but I think we understand each other here.
> In contrast to the analogous lines in /usr/lib/rpm/macros.d/macros.python-srpm
> on Fedora and /usr/lib/rpm/macros.d/macros.python-srpm on rhel9/stream9.
Still correct.
> I also notice that on stream8, koji/cbs's shebang is #!/usr/bin/python3.6, but
> I don't see anything in the koji.spec file that would override the default
> shebang mangling. Most or all of the other python programs in /usr/bin on rhel8
> and stream8 have #!/usr/bin/python3.6 too.
If Koji is built from EPEL, that would explain this. EPEL 8 is overriding
%__python3.
See
https://src.fedoraproject.org/rpms/epel-rpm-macros/blob/epel8/f/macros.zzz-epel-override#_19
and the linked email there.
Basically, EPEL first overrode it to /usr/bin/python3 to undo the RHEL 8 Python
mess and be consistent with Fedora and future RHELs. But since it is supported
to change where /usr/bin/python3 links to in RHEL 8 (using alternatives), we
had to make it more specific.
> So my question is, what really is the correct shebang that should be used on
> rhel8/stream8,
If it a system tool that needs to work even when "no Python is installed", use
/usr/libexec/platform-python.
If you want a specific Python version instead, use that one.
> and how do I achieve it.
BuildRequire python36-rpm-macros, or python39-rpm-macros, or python3.11-rpm-macros.
Or alternatively, set %__python3 to /usr/bin/python3.6 etc.
DO NOT set it to /usr/bin/python3 unless it is a standalone script without
external dependencies that can be executed with any Python 3 version (even all
the future ones).
> I don't want to completely disable
> shebang mangling because it fixes some /bin/sh shebangs. I don't see an easy
> way to use the __mangle_shebangs_exclude macros, but maybe I just have to bite
> the bullet and cons up a file for __mangle_shebangs_exclude_file?
I hope you won't need it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Kaleb
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
