bug#63850: cp fails for files > 2 GB if copy offload is unsupported

[Paul Eggert]

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.