If I understand what you're describing correctly, this is not a bug.
In the default state, /usr/bin/python should *not* exist, that's correct behaviour. If you want it to exist, you need to configure it using alternatives [0].

We considered making /usr/bin/python exist but be a noop, but that breaks a lot of automated (build) tools that search for Python executables (they often start with python, if not found search for python3, or python2, etc.).
And there was no reasonable default for Python in RHEL 8 because it sits between the past (Python 2 default in RHEL 7) and the future (Python3 default in RHEL 9). Either default would cause problems, often hidden and hard to debug problems, for some subset of our customers.

[0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_configuring-the-unversioned-python_configuring-basic-system-settings

Tomas

On Thu, Jul 22, 2021 at 11:58 PM Troy Dawson <tdawson@redhat.com> wrote:


On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok <mhroncok@redhat.com> wrote:
On 22. 07. 21 22:33, Troy Dawson wrote:
>
>
> On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok <mhroncok@redhat.com
> <mailto:mhroncok@redhat.com>> wrote:
>
>     On 22. 07. 21 21:47, Miro Hrončok wrote:
>      > On 22. 07. 21 21:25, Troy Dawson wrote:
>      >> I've been bitten by this yet again.  A package needing /usr/bin/python and
>      >> not python2 or python3.  And it's way down in the code so it's hard to
>      >> patch.  But, it works fine on Fedora.
>      >>
>      >> Is anyone in the middle of porting python-unversioned-command over to
>     epel8?
>      >> If not, does anyone object to me porting it over?
>      >
>      > I wonder how would that package work?
>      >
>      > /usr/bin/python is co-owned by several RHEL-proper packages and managed by
>      > alternatives.
>
>     I hit "Send" to early, apologies, here is the rest of my email:
>
>     Could you please share the package spec file with us (Python Maint team at Red
>     Hat, specifically Tomas Orsava and me) before you actually push it to EPEL, so
>     we get a chance to review it (and maybe test it)?
>
>
> On RHEL 8, if there is something that provides /usr/bin/python I can't find it,
> nor can dnf.
> I've been running RHEL 8 since 8.0, I'm currently at 8.4 and this is what I have.
>
> # dnf provides '/usr/bin/python'
>    Error: No Matches found
> # ls /usr/bin/python
>    ls: cannot access '/usr/bin/python': No such file or directory
> # which python
>    /usr/bin/which: no python in
> (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
>
> On Fedora, it's rather simple, just look at the contents of
> python-unversioned-command
> Two files, no scripts or triggers.
>
> # rpm -ql python-unversioned-command
>    /usr/bin/python
>    /usr/share/man/man1/python.1.gz
> # ls -lh /usr/bin/python
>    lrwxrwxrwx. 1 root root 9 May 18 03:48 /usr/bin/python -> ./python3
> # ls -lh /usr/share/man/man1/python.1.gz
>    lrwxrwxrwx. 1 root root 14 May 18 03:48 /usr/share/man/man1/python.1.gz ->
> ./python3.1.gz
>
> It looks like it will be very simple spec file.
> I'll probably just cut it out of the Fedora python spec file.

On Fedora, it is simple.

On RHEL 8, it is the opposite of simple.

The /usr/bin/python file is managed by alternatives but it deliberately not
owned by any Python package, so `yum install /usr/bin/python` does not work.

If the /usr/bin/python file is created/changed by the admin (or by a package
copied from Fedora), upon (re)installation or upgrade of python2 or
pytohn3{6,8,9} it will be restored based on the alternatives database.

See the %post sctriplets of the mentioned packages.


Ugg ... no wonder nobody has done this yet.
But, is that working right.  It looks like it should be making a /usr/bin/python pointing to unversioned-python but I don't have any of that.
I'm not an Alternatives expert.

I guess what I'm really asking is if this is a bug or not?
I don't have a /usr/bin/python
I do have a /usr/bin/unversioned-python
But, what good is that, nothing calls "unversioned-python"

Should I open a bug on this?  Or continue with my plan of making a fix via a package?
Troy