Btw, if you'd like the details of how this is achieved using alternatives:
The "python" alternative is not actually for /usr/bin/python, but rather
for /usr/bin/unversioned-python, which always exists, and points to either:
- /usr/bin/no-python (default)
- /usr/bin/python3
- /usr/bin/python2
The path /usr/bin/python is added to the alternative definition as a
"slave-link", but only for the /usr/bin/python{2,3} alternative
definitions. So when you enable either Python 2 or Python 3, a slave link
is added by alternatives at /usr/bin/python that points to the same Python
version as /usr/bin/unversioned-python.
Tomas
On Fri, Jul 23, 2021 at 1:36 PM Tomas Orsava <[email protected]> wrote:
> 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 <[email protected]> wrote:
>
>>
>>
>> On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok <[email protected]> wrote:
>>
>>> On 22. 07. 21 22:33, Troy Dawson wrote:
>>> >
>>> >
>>> > On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok <[email protected]
>>> > <mailto:[email protected]>> 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
>>
>>
_______________________________________________
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
