conda-forge/conda-forge-pinning-feedstock

Use alma9 images on linux, while staying on 2.17 sysroot

h-vetinari opened this issue · 19 comments

h-vetinari commented

Since it's taken us so long to upgrade from centOS 6 to 7, we'll very quickly find ourselves in a situation that we struggled with already some time ago (see discussion in this issue): a growing number of feedstocks will require a newer glibc, and our images should provide a new enough baseline version, so that the only thing that feedstocks need to actively override is c_stdlib_version (and thus the sysroot), but nothing else.

For example, google's "foundational" support matrix defines a lower bound of glibc 2.27, meaning that things like abseil/bazel/grpc/protobuf/re2 etc. will start beginning to rely on glibc features >2.17 in the near future (and even though it's not a google project, one of the baseline dependencies of that stack is starting to require it).

We can handle the c_stdlib_version in the migrators (like we did for macOS 10.13, before the conda-forge-wide baseline was lifted), but changing more than one key of the mega-zip involving the docker images is really painful, especially if CUDA is involved (example), so having the images be alma8 by default will be very helpful there.

To a lesser extent, it will also save us from run-time bugs in older glibc versions, like we had with some broken trigonometry functions in 2.12 (before the image moved to cos7 while the sysroot still stayed at 2.12).

There are other scenarios still where this is necessary, see the discussion here for example.

While it's already possible to use alma8 images, the main thing we're blocked is the lack of CDTs for alma 8 (pending conda-forge/cdt-builds#66), c.f. conda-forge/conda-forge.github.io#1941

This issue is for tracking this effort, and any other eventual tasks that need to be resolved before doing so.

hmaarrfk commented

It would be great if we could do this for aarch + cuda12 to start. But I think we should generally move the base image forward.

xref: https://github.com/conda-forge/pytorch-cpu-feedstock/blob/main/recipe/conda_build_config.yaml#L17

h-vetinari commented

AFAIU the only remaining issue is the reduction of CDTs from cos7 to alma8; we should try to do a special "remove/replace CDTs" migration because breaking 100+ feedstocks is not really a good option, even if we provide a way to opt into the old images again.

  • 👍1
hmaarrfk commented

Ah i see, the tk feedstock throws quite a thorn in the "rip out all the CDTs too".

isuruf commented

Using alma8 images and using an up-to-date sysroot are two different problems. In order to change to alma8 images, we just need to check to see if all the requirements in recipe/yum_requirements.txt are available in the alma8 images.

isuruf commented

It doesn't have to be an exhaustive check, but just a few feedstocks that use yum requirements to see if it really works.

jakirkham commented

Wonder if a smaller step would simply making it a bit easier for users to opt-in to using the newer images

Did a little exploration of this in PR: #6548

Likely needs more work, but maybe it is already useful for discussion/iteration at this stage

h-vetinari commented

In order to change to alma8 images, we just need to check to see if all the requirements in recipe/yum_requirements.txt are available in the alma8 images.

So I took the content of all the yum_requirements.txt in conda-forge1. Many of them can be replaced (x11, mesa, alsa, various tool that we have packaged).

entries from
yum_reqirements.txt		 is it still
necessary?		 available
on alma8?		 comment
alsa-lib ❌ ✅ use our alsa-lib
alsa-lib-devel ❌ ✅ use our alsa-lib
alsa-tools ❔ ❌
binutils ✅ ✅ used to bootstrap binutils
csh ❔ ❌ there's tcsh in centos7/alma8, but I cannot find csh in either
chrpath ❌ ✅ used only on obsolete qt feedstock
dbus-devel ❔ ✅
dbus-libs ❔ ✅
dejavu-sans-mono-fonts ❔ ✅ used only for pymor
ed ❔ ✅ used only for bc
file ✅ ✅ used to bootstrap crosstool-ng
findutils ✅ ✅ used to bootstrap linux compilers and crosstool-ng
gcc-c++ ✅ ✅ used to bootstrap linux compilers and binutils
gcc-gfortran ✅ ✅ used to bootstrap linux compilers
gtk2 ❌ ✅ use our gtk2
gtk2-devel ❌ ✅ use our gtk2
gtk3 ❌ ✅ use our gtk3
gtk3-devel ❌ ✅ use our gtk3
gtkmm24 ❔ ✅ use our gtkmm?
hatchling ❌ ❌ cannot find it in either centos7/alma8;
use our hatchling; only used for biosiglive
help2man ✅ ✅ used to bootstrap linux compilers
httpd-devel ❔ ✅ only used for mod_wsgi
kernel-headers ❌ ✅ use our {{ cdt("kernel-headers") }}; only used for gdal
libglu1-mesa ❌ ✅ this is the Debian-style naming; RHEL-style has mesa-libGLU;
use our libglvnd{,-devel}
libglvnd-egl ❌ ✅ use our libglvnd{,-devel}
libglvnd-glx ❌ ✅ use our libglvnd{,-devel}
libglvnd-opengl ❌ ✅ use our libglvnd{,-devel}
libice ❌ ✅ use our xorg-libice
libice-devel ❌ ✅ use our xorg-libice
libselinux ✅ ✅
libsm ❌ ✅ use our xorg-libsm
libsm-devel ❌ ✅ use our xorg-libsm
libudev ❔ ❌ this is the Debian-style naming; we also have our own libudev
libudev-devel ❔ ❌ this is the Debian-style naming; we also have our own libudev
libX11 ✅ ✅ use our xorg-libx11, but needed on python
libX11-devel ❌ ✅ use our xorg-libx11
libXau / libxau ✅ ✅ use our xorg-libxau, but needed on python
libXau-devel ❌ ✅ use our xorg-libxau
libxcb ✅ ✅ use our libxcb, but needed on python
libXcomposite ❌ ✅ use our xorg-libxcomposite
libXcomposite-devel ❌ ✅ use our xorg-libxcomposite
libXcursor ❌ ✅ use our xorg-libxcursor
libXcursor-devel ❌ ✅ use our xorg-libxcursor
libXdamage ❌ ✅ use our xorg-libxdamage
libXdmcp ❌ ✅ use our xorg-libxdmcp
libXdmcp-devel ❌ ✅ use our xorg-libxdmcp
libXext ❌ ✅ use our xorg-libxext
libXext-devel ❌ ✅ use our xorg-libxext
libXfixes ❌ ✅ use our xorg-libxfixes
libXi ❌ ✅ use our xorg-libxi
libXi-devel ❌ ✅ use our xorg-libxi
libXinerama ❌ ✅ use our xorg-libxinerama
libxkbcommon-x11 ❌ ✅ use our libxkbcommon
libXrandr ❌ ✅ use our xorg-libxrandr
libXrandr-devel ❌ ✅ use our xorg-libxrandr
libXrender ❌ ✅ use our xorg-libxrender
libXrender-devel ❌ ✅ use our xorg-libxrender
libXScrnSaver ❌ ✅ use our xorg-libxscrnsaver
libXScrnSaver-devel ❌ ✅ use our xorg-libxscrnsaver
libXt ❌ ✅ use our xorg-libxt
libXt-devel ❌ ✅ use our xorg-libxt
libXtst ❌ ✅ use our xorg-libxst
libXtst-devel ❌ ✅ use our xorg-libxst
libXxf86vm ❌ ✅ use our xorg-libxxf86vm
m4 ✅ ✅ used to bootstrap linux compilers
make ✅ ❌ there is make-latest / make43;
used to bootstrap our binutils and other infra
mesa-dri-drivers ❌ ✅ use our libglvnd{,-devel}
mesa-libEGL ❌ ✅ use our libglvnd{,-devel}
mesa-libEGL-devel ❌ ✅ use our libglvnd{,-devel}
mesa-libGL
mesa-libgl		 ❌ ✅ use our libglvnd{,-devel}
mesa-libGL-devel ❌ ✅ use our libglvnd{,-devel}
mesa-libGLU ❌ ✅ use our libglvnd{,-devel}
mesa-libGLU-devel ❌ ✅ use our libglvnd{,-devel}
numactl ❌ ✅ use our numactl
numactl-devel ❌ ✅ use our numactl
patch ✅ ✅ used to bootstrap linux compilers
pciutils ❔ ✅
pciutils-devel ❔ ✅
pciutils-libs ❔ ✅
perl ❌ ✅ use our perl
pulseaudio-libs-devel ❌ ✅ use our pulseaudio; only used for pocketsphinx-python
python-docutils ❌ ❌ there's python3-docutils; but use our docutils;
only used for rdma-core
rsh ❔ ❌ no idea what this is for
rsync ✅ ✅ used to bootstrap linux compilers
sed ✅ ✅ used to bootstrap linux compilers and crosstool-ng
systemd-devel ❔ ✅ we have our own libsystemd
texinfo ✅ ✅ used to bootstrap our binutils
util-linux ❌ ✅ use our util-linux
wget ✅ ✅ used to bootstrap linux compilers
xauth ❌ ❌ doesn't exist on either centos7/alma8,
but xorg-x11-xauth exists in both; but use our xorg-xauth
xorg-x11-server-Xorg ❔ ✅
xorg-x11-server-Xvfb ❔ ✅

Footnotes

  1. probably. depends on whether the github search for that is truly exhaustive ↩

jakirkham commented

Thanks for pulling together this list Axel and going over it in today's call! 🙏

Cleaned up the rdma-core case. It also uses systemd

What do we think about making a migrator? At least with X11, this seems essential given that gets pulled in all over the place. Though this may extend to other places

h-vetinari commented

What do we think about making a migrator?

My understanding was that a migrator is not necessary. The yum_requirements will continue to work, and if CDTs end up missing they can be replaced with our own deps, or alternatively users set os_version: cos7 in their conda-forge.yml