ENH set date for cos6 EOL #1980
Conversation
| 2023-07-12: End-of-life for CentOS 6 | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| As you may be aware, we have delayed the deprecation of our CentOS 6 build | ||
| system the ``linux64`` platform several times. We have now set a formal deprecation | ||
| date to be June 30, 2024. This date matches the | ||
| `end of extended life-cycle support <https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel>`_ | ||
| from RedHat for RHEL 6. After this date, we build packages against | ||
| CentoOS 7 by default for ``linux64``. |
There was a problem hiding this comment.
This is the EOL for CentOS 6 & 7. So don't think we can move to CentOS 7 then
There was a problem hiding this comment.
I'm happy to change the wording here, but I think jumping past cos7 will be hard for the same reasons cos6 was. We will have a bunch of users with legacy systems and we don't formally need to jump ahead, so it makes more sense to stick with cos7.
There was a problem hiding this comment.
Also this isn't standard EOL. This date is for their extended lifecycle support maintenance. That goes until June 30, 2028 for cos7. See https://access.redhat.com/support/policy/updates/errata#Extended_Life_Cycle_Phase
The June 30, 2024 date is the end of extended lifecycle support for cos6.
So going to cos7 and using it until 2028 would be consistent.
There was a problem hiding this comment.
That link is for RedHat. Not CentOS. The CentOS page confirms what the other link stated. Namely CentOS 7 is EOL 30 June 2024
https://wiki.centos.org/About/Product
Appreciate that the situation is messy due to the RedHat changes. However we can't control that. All we can control is the safety of our own infrastructure, which gets significantly harder once CentOS 7 goes EOL. Are we planning to maintain CentOS 7 ourselves? What is our plan?
There was a problem hiding this comment.
Maybe we can look at how long the UBI images are around and what it would take to migrate our infrastructure to them
There was a problem hiding this comment.
Yes I know the link was for redhat. My point is simply that some people who use conda-forge may still be on cos7 even if it is past EOL.
There was a problem hiding this comment.
Yeah that's fine, but we need to have a way to support them if we are going to make that kind of promise. Red Hat is making that harder
There was a problem hiding this comment.
We are not making a promise of 4 years of cos 7 support with this announcement. We are simply saying that when we turn off Cos6, we will use cos 7. We can choose to deprecate cos7 a day later if we please.
|
With my hat of NumPy maintainer, this puts us in a difficult position. It means we should continue to support glibc-2.12 for another year (I seem to remember we already removed code to support it when CentOS6 went EOL at the end of 2020) and also support the manylinux2014 standard glibc-2.17 after manylinux2014 is "officially" EOL. We were looking forward to ripping out some work-arounds we have for buggy glibc-2.17 math routines. |
|
@mattip There is no need for numpy to continue to support glibc-2.12, we can override it on a per-feedstock basis and already do for many packages. See https://conda-forge.org/docs/maintainer/knowledge_base.html#using-centos-7 People can continue to get updates of downstream packages and rely on us building with older numpy ABIs to still be able to use the newer downstream packages while using an older numpy. |
|
The only place we might have an annoying issue is for Python 3.12 as if there isn't a version of numpy that supports both 3.12 and CentOS 6 (but that's a purely conda-forge issue and I can think of workarounds). |
|
That said, if NumPy requires GLIBC 2.17+, are we gaining much by keeping GLIBC 2.12? Basically the PyData stack needs to move to GLIBC 2.17+ |
|
I fear maintaining the patches to revert post glibc-2.17 changes to the blocklisted math functions may be a large maintenance burden on conda-forge. Luckily, MSVC support mandates we keep some of these blocklisted functions around, but if Microsoft fixes those, we could drop them which would greatly clean up NumPy internals. |
|
Is there an open issue tracking NumPy's GLIBC update plans? |
|
Not really. There is a numpy issue about npymath with a wide-ranging discussion around many things, among them math routine support in the OS runtime. I did open an issue in the canonical guide to PEP 600 compliance mayeut/pep600_compliance#306 which so far has been my guide to manage manylinux (and thus glibc) deprecation |
|
I think we shouldn't make an argument based on the extended EOL, because it's completely irrelevant to our infra (it's not like we'd get any updates, nor do we need them really). We just decided to support compatibility with old Linux longer due to known users being affected. I don't think we should establish an expectation that our support is related to the end of rhel's extended EOL. It was and remains based on our goodwill to support things as long as possible, but if a big problem arises we should be free to move |
|
I didn't mean to imply we should base our lifecycle on RedHat. I was trying to point out that even if CentOS7 is past EOL, folks still may be using it just like what happened with CentOS6. I 100% agree it is based on our maintenance capacity. We have to move to something when we deprecate CentOS6 and simply going to CentOS7 is by far the easiest thing. Individual feedstocks can move ahead as they please. |
conda-forge#1980 Co-authored-by: Matthew R. Becker <[email protected]>
PR Checklist:
Xref: #1436