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/...
Tomas
On Thu, Jul 22, 2021 at 11:58 PM Troy Dawson <tdawson(a)redhat.com> wrote:
On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok <mhroncok(a)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(a)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