On Tue, Jul 27, 2021 at 6:50 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 27. 07. 21 23:03, Neal Gompa wrote: > > On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava <torsava@xxxxxxxxxx> 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 > >> > > > > 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 > 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@xxxxxxxxxxxxxxxxxxxxxxx/thread/WNNAZWWHDU7LE4EJBDKREJO5FJQ6SXRX/ > > 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 > Unfortunate, but sensible. > > 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 > 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! _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
