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

From: Sam James <[email-masked]>
Date: Tue, 06 Jun 2023 06:09:16 +0100

Paul Eggert <[email-masked]> writes:

> On 2023-06-03 06:54, Mike Gilbert wrote:
>> In this case, headers from linux-6.1 are being used at build time.
>> However, the code is being run on a linux-4.19 kernel.
>
> Gnulib doesn't support that. If you build with headers from a
> particular version of the operating system, you can't necessarily run
> on older versions. The reasons for this sort of restriction should be
> obvious.
>

This is a principle that other core parts of userland have no issue
with. For example, util-linux has various fallbacks based on the
*runtime* kernel version.

This doesn't square with reality, anyway: if I install linux-6.1
and its headers, then I downgrade, I need to then rebuild every
piece of the userland I built against the new headers. Tracking
that as a user is nontrivial.

> If Gentoo builds are regularly targeting older kernels or libraries
> than the platform they are building on, then surely that's a problem
> in general, not just here.

Now, continuing from what I said above, it's not feasible to *require*
users to use a kernel from the package manager. Not only do users want
to be able to run their own kernel (sometimes even just for a quick
test), but this is completely incompatible with having multiple kernels
installed in parallel, as you can't have multiple versions of the
same linux-headers in /usr/include.

Going further: are we really suggesting that someone who was using
say, Linux 6.1 for a few days, then downgrades to Linux 5.15 to test
something is in an unsupported configuration?

This isn't a practical position to have. This assumption *barely*
holds for binary distributions where you "upgrade the world" all
at once, and as I said, it's questionable there. And it's completely
incompatible with source-based distributions.

>
> I'll cc this to bug-gnulib to give them a heads-up about the
> issue. For gnulib readers, the original bug report is here:
>
> https://bugs.gnu.org/63850