systemd requires a kernel newer than 3.10.

Yes but systemd is not needed in general if using arch as a docker container or similar.

systemd almost certainly is required, even if it's not used as init. As they set the absolute minimum at 3.15, it's hard to say what all wouldn't work with older kernels.

Things work fine in general for software development/scientific applications/etc when running a container with a rebuilt glibc (it's just a maintenance hassle to have to stay in sync and rebuild it)

The deprecation notice has been issued end of 2020. There have been more than 1.5 years transition period already. How long do we expect the migration to take?

End of maintenance updates for CentOS 7 is June 30, 2024 so this could be a reasonable end-point. (Most institutions I'm aware of still using CentOS 7 are aiming to upgrade to something else by then at the absolute latest.)

I'm not willng to put something in the distro repo for years that hasn't anything todo with Arch really. Though, if there are enough people interested in this "glibc-compat" thingy, I'm willing to put it in a private users repo.

Ok but is there any significant drawback to this? glibc itself still supports older kernels upstream just fine (and I think the default would even be to maintain more backwards compatibility).

Also there ARE official docker images for Arch on Docker Hub so this is a "supported" way of using arch somehow, just a question of how broad a range of host systems are supported.

If we'd officially support older kernels, we'd need to test them if issues occur. Linux 3.x is not in our repos, nor is it LTS according to kernel.org.
So there is more work required than just changing a configure parameter.

I can't state anything about the support of our docker images. Though I doubt that unsupported kernels is something we aim at.

Feel free to apply as Developer to help maintain glibc if the offered solution doesn't suit your needs.

Well just changing the parameter would already help users who are trying to use arch-based containers in this way with little or no drawback.
(Most other major distros seem to still support older kernels in their glibc builds, most likely for this reason)


Presumably the full combination of host systems/kernels for running containers is not really tested anyways (arch images work on RHEL8 or clones for example, but those have their own kernels etc etc)

This is basically a dupe of  FS#69663 . The decision for 4.4 was made here [1]. The rationale back then was sound, but waters were somewhat muddied due to multiple issues being conflated. FWIW both Fedora/Debian appear to be using 3.2.

Back in the very old days, `--enable-kernel=x.y.z' could be used to cut out a lot of compatibility cruft. This made your glibc go faster! Looking at current `sysdeps/unix/sysv/linux/kernel-features.h' the macros impacted by the difference between 3.2 and 4.4 is not many, maybe 3 or so. Therefore, if we went back to 3.2, our glibc would be slower (but not by a noticeable amount I'm guessing).

Anyway, I vote for the status quo :)

[1] https://bugs.archlinux.org/task/69563#comment196734

We're not "just changing parameters". If there are enough people interested in this, I'll consider a separate (private) repo to help with the migration.
But this is a no for the Arch repo from my side.