roll-out of alma8-based infrastructure (aka centos 8)

[beckermr]

This issue tracks centos 8 implementation PRs

• build sysroots from alma 8
  • This one is subtle since we need to weigh down the newer sysroots on ppc64le / aarch64 / s390x using track_features.
  • We likely will also need the current repodata hack package on ppc64le / aarch64 / s390x.
  • To use the curr repodata hack package, we'll need to patch the cos7 sysroots to depend on it.
  • rebuild current cos7 sysroots with current repodata hack (ENH add current repodata hack on non-x86_64 for 2.17 in prep for 2.28 linux-sysroot-feedstock#46)
  • submit repodata patch to add current repodata data hack to cos7 sysroots (ENH add repodata patch to make sure 2.17 sysroots are in current repo… conda-forge-repodata-patches-feedstock#441)
  • add new sysroots with track_features (ENH glibc 2.28 from alma8 linux-sysroot-feedstock#47)
• build docker images
  • ENH Add AlmaLinux 8 based image docker-images#235
  • Provide linux-anvil-cuda on x64 with RHEL 8, consolidate image names, distinguish distro baseline in tag docker-images#291
• build CDTs from alma 8
  • make sure cdt_name is conda_2_28 just conda now
  • decide which cdts to build (c.f. figure out which CDTs we can drop for cos8, maybe drop them all? cdt-builds#66)
  • Add first batch of alma8 CDTs cdt-builds#70
• Use alma9 images on linux, while staying on 2.17 sysroot conda-forge-pinning-feedstock#6283
  • move to alma9 by default; enable choice through DEFAULT_LINUX_VERSION conda-forge-pinning-feedstock#6626
• adjust staged recipes for alma8: update images to use alma9 staged-recipes#28326
• test compilers

The alma 8 repo is https://repo.almalinux.org/almalinux/8.7/BaseOS/x86_64/os/Packages/ etc.

[jaimergp]

xrefs:

• CentOS 8 #1432
• This week's meeting notes

[jaimergp]

What I understood was:

• We will build the new sysroots from Alma 8
• Alma 8 happens to use Glibc 2.28
• manylinux_2_28 is also derived from Alma 8, so that's the match?
• Anaconda versions their sysroots with the glibc version, and we do too?
• The cosN (CentOs version N) prefixes we had in some places will be replaced by conda_X_YZ (with X.YZ being the glibc version)

And maybe I am missing something else, but we can probably merge the discussion with the CentOS 8 thread mentioned in my comment above.

[beckermr]

Someone, I think @isuruf, mentioned listing versions for other things. libm maybe?

[h-vetinari]

The cosN (CentOs version N) prefixes we had in some places will be replaced by conda_X_YZ (with X.YZ being the glibc version)

Manylinux uses glibc major.minor for its versioning, and I think it's good to match that (I think in the core call the mood was that conda_2_28 would be the best option).

That said, not least after the ill-fated Debian-based manylinux_2_24, in effect it's been just a way to encode the RHEL major version:

manylinux	glibc	RHEL
manylinux1	2.5	5
manylinux2010	2.12	6
manylinux2014	2.17	7
manylinux_2_28	2.28	8

That's because manylinux cannot bring its own updated compiler stack along and so is dependent on having the devtoolset backports. Perhaps keeping RHEL X as a base (through one of its ABI-compatible derivatives like Alma,Rocky,UBI) solves the other versioning questions, even if we call it conda_2_28?

[beckermr]

Yes. We plan to keep alma8 as the base.

[isuruf]

One plus about just using conda instead of conda_2_28, is that the user does not have to deal with cdt_name in the recipes. They can just use the versioning of the sysroot and the cdt_name will become obsolete.

[beckermr]

We'll need to tuck the cdt name in the CDTs somewhere maybe? Idk if the CDT package names will conflict or not.

[beckermr]

Can you send an example recipe where people are dealing directly with cdt_name? I thought the jinja2 function took care of that.

[isuruf]

For eg: https://github.com/conda-forge/qt-main-feedstock/blob/main/conda-forge.yml#L18-L19

[isuruf]

On the other hand, that line in conda-forge.yml serves two purposes. Setting cdt_name and the docker image name.

[beckermr]

Hmmmm. Being able to at least match cdts to the os for our docker containers is inherently useful possibly? This would argue for using conda_2_28 in both places.

[isuruf]

Being able to at least match cdts to the os for our docker containers is inherently useful possibly?

That's not really needed. We use cos6 CDTs in cos7 docker images.

[beckermr]

I'm not saying we alway have to have them matched. I'm saying that using the same notation in both places is helpful.