On 2023-06-07 12:21, Sam James wrote:
I don't see how this is compatible with what I explained, given you
can't have parallel linux-headers installs.
Nobody uses glibc in a vacuum, either, so it's not particularly
meaningful to say you can use glibc but nothing else in that way.
If you object to this, please bring it up on the glibc mailing list
to discuss revising the guidance.
There must be some miscommunication here. I'm not objecting to how glibc
is built, and I don't see why the glibc mailing list would be interested
in this problem as it's not their problem.
We can't enforce
what kernels users are running, and we can't simultaneously make the
users install the headers for the kernel they just built manually while
also having things owned and controlled by the package manager.
We're also very much not the only distribution doing this - Arch
usually ships the latest linux-headers, and Alpine does as well.
And we've done it for years with very, very few issues.
That's not surprising, as this sort of problem arises only when building
for a newer platform yields a package that will run incorrectly on an
older platform. Problems like these are relatively rare if the only such
mismatch is the Linux kernel version, because current glibc explicitly
supports building for Linux kernel>=3.2, even when glibc is built on
newer kernels, these days nobody doing this sort of thing cares about
kernels older than 3.2, and most packages rely entirely on glibc to
access the kernel. There are exceptional packages, though, and you may
run into problems with those exceptions.
If users build for newer platforms and it usually works on older
platforms, that's great! But you might want to document that it might
not work. Because it might not.