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?
Troy
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.
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 Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok 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.
Troy
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.
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'shard to
>> patch. But, it works fine on Fedora. >> >> Is anyone in the middle of porting python-unversioned-commandover 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 andmanaged 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 Maintteam at Red
Hat, specifically Tomas Orsava and me) before you actually push itto 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
On 22. 07. 21 23:58, Troy Dawson wrote:
On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok <mhroncok@redhat.com mailto: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> > <mailto: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?
I am not entirely sure I understand the bug you are describing.
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/htm...
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'shard to
>> patch. But, it works fine on Fedora. >> >> Is anyone in the middle of porting python-unversioned-commandover 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 andmanaged 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 Maintteam at Red
Hat, specifically Tomas Orsava and me) before you actually push itto 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
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 torsava@redhat.com 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/htm...
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'shard to
>> patch. But, it works fine on Fedora. >> >> Is anyone in the middle of porting python-unversioned-commandover 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 andmanaged 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 Maintteam at Red
Hat, specifically Tomas Orsava and me) before you actually push itto 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
On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava torsava@redhat.com 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/htm...
But this won't be a problem in RHEL 9, will it? I don't want to suffer through this when we're not even going to have Python 2 in RHEL 9 at all...
On Tue, Jul 27, 2021 at 2:04 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava torsava@redhat.com 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/htm...
But this won't be a problem in RHEL 9, will it? I don't want to suffer through this when we're not even going to have Python 2 in RHEL 9 at all...
It will not be a problem in RHEL9. I just verified and it is setup like Fedora
[root@cs9 ~]# which python /usr/bin/python [root@cs9 ~]# rpm -qf /usr/bin/python python-unversioned-command-3.9.5-3.el9.noarch [root@cs9 ~]# dnf provides '/usr/bin/python' python-unversioned-command-3.9.6-1.el9.noarch : The "python" command that runs Python 3 Repo : cs9-appstream Matched from: Filename : /usr/bin/python
On 27. 07. 21 23:03, Neal Gompa wrote:
On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava torsava@redhat.com 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/htm...
But this won't be a problem in RHEL 9, will it? I don't want to suffer through this when we're not even going to have Python 2 in RHEL 9 at all...
Not at all. We have reviewed all the RHEL 8 differences from Fedora and how much painful they were/are and decided to play the "if we would not do this in Fedora, we should not do it in RHEL 9 either" card. That includes /usr/bin/python (optionally (un)installable but only one), platform-python (don't), modularity (don't), and other things.
Some differences are still planned though, albeit hopefully minor:
1) We plan non-modular parallel-installable Python stacks in RHEL 9, but we don't want to take care of such stacks in Fedora. However, we intent to fully support this case for Fedora's downstreams (not only RHEL: any downstream, e.g. even Copr repos): https://bugzilla.redhat.com/show_bug.cgi?id=1821489
2) We need some upgrade-path compatibility shims from RHEL 8's platform-python that are not needed in Fedora and we plan to include them in RHEL 9 only: https://bugzilla.redhat.com/show_bug.cgi?id=1891487
3) In Fedora, various Python interpreters use pip/setuptools/wheel wheels from /usr/share/python-wheels or bundle their own wheel when the "general" ones are too new to work with old Pythons. Given the differences of life cycle of RHEL and Fedora, we plan to use wheels from /usr/share/python3.X-wheels instead (and have the possibility to build newer versions of pip/setuptools/wheel wheels for each newer Python version we introduce to RHEL 9). RHEL 8 already partially does that for Python 3.8+, but in RHEL 9, we want to do this from the beginning. I intent to do the rpm-macros-groundwork for this in Fedora, but we might need to explicitly not make this change in ELN to preserve Rawhide/ELN builds compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1982668
Usual disclaimer applies: Those are our plans as engineers, not promises by Red Hat as a company.
On Tue, Jul 27, 2021 at 6:50 PM Miro Hrončok mhroncok@redhat.com wrote:
On 27. 07. 21 23:03, Neal Gompa wrote:
On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava torsava@redhat.com 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/htm...
But this won't be a problem in RHEL 9, will it? I don't want to suffer through this when we're not even going to have Python 2 in RHEL 9 at all...
Not at all. We have reviewed all the RHEL 8 differences from Fedora and how much painful they were/are and decided to play the "if we would not do this in Fedora, we should not do it in RHEL 9 either" card. That includes /usr/bin/python (optionally (un)installable but only one), platform-python (don't), modularity (don't), and other things.
Some differences are still planned though, albeit hopefully minor:
- We plan non-modular parallel-installable Python stacks in RHEL 9, but we
don't want to take care of such stacks in Fedora. However, we intent to fully support this case for Fedora's downstreams (not only RHEL: any downstream, e.g. even Copr repos): https://bugzilla.redhat.com/show_bug.cgi?id=1821489
I think if we had some more automation about building whole stacks and some way to dynamically generate subpackages, this could be something to bring to Fedora itself. But for now, this makes sense.
I think we discussed this somewhat earlier in the year[1], it's something we can revisit if the situation improves...
[1]: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje...
- We need some upgrade-path compatibility shims from RHEL 8's platform-python
that are not needed in Fedora and we plan to include them in RHEL 9 only: https://bugzilla.redhat.com/show_bug.cgi?id=1891487
Unfortunate, but sensible.
- In Fedora, various Python interpreters use pip/setuptools/wheel wheels from
/usr/share/python-wheels or bundle their own wheel when the "general" ones are too new to work with old Pythons. Given the differences of life cycle of RHEL and Fedora, we plan to use wheels from /usr/share/python3.X-wheels instead (and have the possibility to build newer versions of pip/setuptools/wheel wheels for each newer Python version we introduce to RHEL 9). RHEL 8 already partially does that for Python 3.8+, but in RHEL 9, we want to do this from the beginning. I intent to do the rpm-macros-groundwork for this in Fedora, but we might need to explicitly not make this change in ELN to preserve Rawhide/ELN builds compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1982668
Aren't wheels fully versioned themselves? Why do you need the wheel directory itself to be versioned?
Usual disclaimer applies: Those are our plans as engineers, not promises by Red Hat as a company.
Naturally. :)
-- 真実はいつも一つ！/ Always, there's only one truth!
On 28. 07. 21 1:19, Neal Gompa wrote:
- In Fedora, various Python interpreters use pip/setuptools/wheel wheels from
/usr/share/python-wheels or bundle their own wheel when the "general" ones are too new to work with old Pythons. Given the differences of life cycle of RHEL and Fedora, we plan to use wheels from /usr/share/python3.X-wheels instead (and have the possibility to build newer versions of pip/setuptools/wheel wheels for each newer Python version we introduce to RHEL 9). RHEL 8 already partially does that for Python 3.8+, but in RHEL 9, we want to do this from the beginning. I intent to do the rpm-macros-groundwork for this in Fedora, but we might need to explicitly not make this change in ELN to preserve Rawhide/ELN builds compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1982668
Aren't wheels fully versioned themselves? Why do you need the wheel directory itself to be versioned?
(This entire answer applies to pure-python wheels only, which is what we ship anyway.)
They include the version of the project, not version of the Python interpreter. They only declare Python 2/3 compatibility in the name:
$ ls -1 /usr/share/python-wheels/ pip-20.2.2-py2.py3-none-any.whl setuptools-49.1.3-py3-none-any.whl wheel-0.34.2-py2.py3-none-any.whl
epel-devel@lists.fedoraproject.org
-
Miro Hrončok -
Neal Gompa -
Tomas Orsava -
Troy Dawson