8 ms·

Yay! Glad to see this rather than the Red Hat approach of continuing to support dead versions (yes, I know that enterprises value stability blah blah blah)

solarengineer 5y ago
The way I have always understood it - the Python that RedHat supplies is intended for it's scripts. If we install our own packages or remove any packages, then the risk destabilising the system. I have seen situations where people have removed python packages that resulted in yum no longer working, for e.g. Hence, I have always (including from the RHEL 6.x days) provided my own local python version by compiling and packing as a custom rpm. I now use venv to do the same.
- Un1corn 5y ago
  Actually RedHat no longer ships Python since RHEL 8, instead they have platform-python for internal use of the operating system and you need to explicitly install the Python version you want
  - mroche 5y ago
    This is a RHEL 8 only feature, RHEL 9 will have a global python3. Whether alternative version are offered as modules or as side-by-side installs like in Fedora, I do not know. https://koji.fedoraproject.org/koji/search?terms=python%5B2-3%5D.%28%5B5-9%5D%7C%5B0-9%5D%5B0-9%5D%29&type=package&match=regexp https://koji.fedoraproject.org/koji/search?terms=python%5B2-...
tombert 5y ago
When I was at Apple, they discontinued bundling the command line version of emacs, and they sent a long internal email stating why. The stated reason was that any newer emacs would suffer from license incompatibility with macOS, and they didn't see the point of supporting a 10 year old version that the FSF doesn't even support when, if someone really wants emacs, it's just a `brew install emacs` away. I can't say I disagree.
- tambourine_man 5y ago
  I don't disagree either, but the whole GPLv3 situation is still not solved after all this years. Will they completely remove bash, rsync, eventually?
  - pininja 5y ago
    I seem to remember they just switch default shell to zsh, which is MIT [0] [0] https://github.com/zsh-users/zsh/blob/master/LICENCE https://github.com/zsh-users/zsh/blob/master/LICENCE
    - salamanderman 5y ago
      And if you change your default back to bash, every new terminal you open complains that you should switch to zsh
      - sigjuice 5y ago
        export BASH_SILENCE_DEPRECATION_WARNING=1
      - Klonoar 5y ago
        Not if you install a modern bash, unless I’ve missed something all these years.
        salamanderman 5y ago
        What I see when I open a terminal is this: The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050 https://support.apple.com/kb/HT208050. I believe I switched from the default zsh to the bash that also came with the operating system. I don't think I installed a new bash. I was just trying to add on to/respond to the question "Will they completely remove bash, rsync, eventually?" . My answer was too short and I didn't actually make it clear what I was saying. I think the answer to the question "Will they completely remove bash, rsync, eventually?" is yes, at least for bash, I think they will remove it. My evidence for thinking they'll remove it is if you switch from the default zsh to the bash that comes with the operating system, they'll kindly ask you to switch back to zsh every time you open the terminal. Yes, you can change the default from nagging you with BASH_SILENCE_DEPRECATION_WARNING, which is great to know.
mroche 5y ago
RHEL and macOS are two very different products with two very different audiences and can hardly be compared like this. That being said, Python 2 will last through the end of RHEL 7's lifespan through June 2024, and that includes the AppStream module in RHEL 8 which will similarly end support in June 2024. After that customers are recommended to upgrade to a supported version of Python or continue using Python 2.7 at their own self-supported risk, we will not support them in that endeavor. RHEL 9 (due out in a few months) does not ship Python 2.7. https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle https://access.redhat.com/support/policy/updates/rhel8-app-s...
- seanw444 5y ago
  With Ubuntu, if you delete Python, it obliterates everything. Have fun re-installing your system. Learned that the hard way. You can bet I "use Arch btw" now.
  - mroche 5y ago
    I don't see how that's relevant here, unless you interpreted my statement to mean we will be removing Python 2.7 in RHEL 8. That isn't happening, the module will remain in the AppStream repositories but will not receive any support. Removing the system Python is prevented on RHEL/Fedora (with an exception). The package manager, DNF and YUM, are marked as protected which prevent their removal. You'd need to remove the protection file from /etc/dnf/protected.d before you can do that. Removing the system python would remove the package manager which depends on it, therefore the transaction is stopped. Using the RPM utility directly also will not work unless you a) pass --nodeps or b) list out every single dependency at the same time manually. You can test this in the CentOS containers with the following: quay.io/centos/centos:7: yum remove python rpm -ev python quay.io/centos/centos:stream8 dnf remove platform-python rpm -ev platform-python quay.io/centos/centos:stream9 dnf remove python3 rpm -ev python3 Best practice policy: use yum/dnf, not rpm for any package management.
    - seanw444 5y ago
      You're right, it's not relevant here. I somehow managed to replied to you instead of the comment I was thinking about responding to. Weird.
jdkjs 5y ago
Why is it bad that red hat does that? That’s what their clients pay them for.
leokennis 5y ago
It’s not just “value stability”, there’s a good chance that without them knowing some part of their billion dollar enterprise absolutely depends on an old python component that would break if 2.7 were removed. They know that at some point, their RHEL version runs out of extended support. Two years before that they’ll experiment with the new RHEL version on their test environment and notice everything is totally broken. And then they’ll have two years to fix it which is just barely enough time, as “fixing it” requires buy in and planning and resources from dozens of divisions and hundreds of people. To enterprises, having Red Hat support some ass backwards old version of whatever package is not just “valued”, it’s exactly why they pay millions to Red Hat instead of running some free Linux version.

solarengineer 5y ago

The way I have always understood it - the Python that RedHat supplies is intended for it's scripts. If we install our own packages or remove any packages, then the risk destabilising the system. I have seen situations where people have removed python packages that resulted in yum no longer working, for e.g. Hence, I have always (including from the RHEL 6.x days) provided my own local python version by compiling and packing as a custom rpm. I now use venv to do the same.

Un1corn 5y ago
Actually RedHat no longer ships Python since RHEL 8, instead they have platform-python for internal use of the operating system and you need to explicitly install the Python version you want
- mroche 5y ago
  This is a RHEL 8 only feature, RHEL 9 will have a global python3. Whether alternative version are offered as modules or as side-by-side installs like in Fedora, I do not know. https://koji.fedoraproject.org/koji/search?terms=python%5B2-3%5D.%28%5B5-9%5D%7C%5B0-9%5D%5B0-9%5D%29&type=package&match=regexp https://koji.fedoraproject.org/koji/search?terms=python%5B2-...

tombert 5y ago

When I was at Apple, they discontinued bundling the command line version of emacs, and they sent a long internal email stating why. The stated reason was that any newer emacs would suffer from license incompatibility with macOS, and they didn't see the point of supporting a 10 year old version that the FSF doesn't even support when, if someone really wants emacs, it's just a `brew install emacs` away. I can't say I disagree.

tambourine_man 5y ago
I don't disagree either, but the whole GPLv3 situation is still not solved after all this years. Will they completely remove bash, rsync, eventually?
- pininja 5y ago
  I seem to remember they just switch default shell to zsh, which is MIT [0] [0] https://github.com/zsh-users/zsh/blob/master/LICENCE https://github.com/zsh-users/zsh/blob/master/LICENCE
  - salamanderman 5y ago
    And if you change your default back to bash, every new terminal you open complains that you should switch to zsh
    - sigjuice 5y ago
      export BASH_SILENCE_DEPRECATION_WARNING=1
    - Klonoar 5y ago
      Not if you install a modern bash, unless I’ve missed something all these years.
      - salamanderman 5y ago
        What I see when I open a terminal is this: The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050 https://support.apple.com/kb/HT208050. I believe I switched from the default zsh to the bash that also came with the operating system. I don't think I installed a new bash. I was just trying to add on to/respond to the question "Will they completely remove bash, rsync, eventually?" . My answer was too short and I didn't actually make it clear what I was saying. I think the answer to the question "Will they completely remove bash, rsync, eventually?" is yes, at least for bash, I think they will remove it. My evidence for thinking they'll remove it is if you switch from the default zsh to the bash that comes with the operating system, they'll kindly ask you to switch back to zsh every time you open the terminal. Yes, you can change the default from nagging you with BASH_SILENCE_DEPRECATION_WARNING, which is great to know.

mroche 5y ago

RHEL and macOS are two very different products with two very different audiences and can hardly be compared like this. That being said, Python 2 will last through the end of RHEL 7's lifespan through June 2024, and that includes the AppStream module in RHEL 8 which will similarly end support in June 2024. After that customers are recommended to upgrade to a supported version of Python or continue using Python 2.7 at their own self-supported risk, we will not support them in that endeavor. RHEL 9 (due out in a few months) does not ship Python 2.7. https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle https://access.redhat.com/support/policy/updates/rhel8-app-s...

seanw444 5y ago
With Ubuntu, if you delete Python, it obliterates everything. Have fun re-installing your system. Learned that the hard way. You can bet I "use Arch btw" now.
- mroche 5y ago
  I don't see how that's relevant here, unless you interpreted my statement to mean we will be removing Python 2.7 in RHEL 8. That isn't happening, the module will remain in the AppStream repositories but will not receive any support. Removing the system Python is prevented on RHEL/Fedora (with an exception). The package manager, DNF and YUM, are marked as protected which prevent their removal. You'd need to remove the protection file from /etc/dnf/protected.d before you can do that. Removing the system python would remove the package manager which depends on it, therefore the transaction is stopped. Using the RPM utility directly also will not work unless you a) pass --nodeps or b) list out every single dependency at the same time manually. You can test this in the CentOS containers with the following: quay.io/centos/centos:7: yum remove python rpm -ev python quay.io/centos/centos:stream8 dnf remove platform-python rpm -ev platform-python quay.io/centos/centos:stream9 dnf remove python3 rpm -ev python3 Best practice policy: use yum/dnf, not rpm for any package management.
  - seanw444 5y ago
    You're right, it's not relevant here. I somehow managed to replied to you instead of the comment I was thinking about responding to. Weird.

jdkjs 5y ago

Why is it bad that red hat does that? That’s what their clients pay them for.

leokennis 5y ago

It’s not just “value stability”, there’s a good chance that without them knowing some part of their billion dollar enterprise absolutely depends on an old python component that would break if 2.7 were removed. They know that at some point, their RHEL version runs out of extended support. Two years before that they’ll experiment with the new RHEL version on their test environment and notice everything is totally broken. And then they’ll have two years to fix it which is just barely enough time, as “fixing it” requires buy in and planning and resources from dozens of divisions and hundreds of people. To enterprises, having Red Hat support some ass backwards old version of whatever package is not just “valued”, it’s exactly why they pay millions to Red Hat instead of running some free Linux version.