Koji build failure with coreutils-7.5

[Jim Meyering]

Jeff Garzik wrote:
> On 08/24/2009 03:11 AM, Jim Meyering wrote:
>> Jim Meyering wrote:
>>> Todd Zullinger wrote:
>>>> I tried to build a git update into dist-f12-openssl earlier and had it
>>>> die in %doc with an error from cp¹:
>>>>
>>>> cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented
>>>
>>> Hi Todd,
>>>
>>> This is because that latest version of coreutils tries to preserve
>>> permissions on symlinks when it thinks that is possible.
>>> It determines whether to try by testing at configure time for the
>>> existence of the utimensat function.  If it can compile and link
>>> against that function, then the resulting executable will call it
>>> and report any failure.  The trouble is when you configure on a system
>>> with recent libraries and headers, yet *run* with a kernel
>>> that is old enough as to lack the syscall.
>>
>> By the way, to those who maintain koji,
>>
>> It is subtly dangerous to configure a package against headers and
>> libraries that are not well-matched with the kernel.
>> In this case, new headers/libraries suggest a function is available,
>> as detected by a standard autoconf function-existence check.
>> Yet only at run time do we detect (via surprising failure with ENOSYS)
>> that the kernel is too old to support the function that we were led
>> to believe would be available.  Here, it wasn't that big a deal,
>> but I can easily imagine this sort of mismatch leading to a more
>> serious problem.
>>
>> It is fine to have a kernel *newer* than would be suggested by
>> headers/libraries.  Now you've seen why is risky to use one that is older.
>
> Unfortunately this is quite common for build machines...  as it is
> easy to build any number of buildroots for any number of OS's.
>
> But since one cannot chroot into a new kernel, to build with new
> libraries/headers, the kernel remains inevitably older than that which
> the machine builds.
>
> The only other alternative I can think of is booting a virtual machine
> for each package build, which I imagine is probably too costly/painful
> to consider for koji...

Actually, that sounds like the real solution:
build packages for F11 in a VM running F11's base kernel,
build packages for F10 in a VM running F10's base kernel, etc.

coreutils/Fedora had similar hassles with the various *at functions,
too (openat, fstatat, etc.), and I suspect we haven't seen the
last of this sort of problem.  But maybe it is infrequent enough
not to deserve a "real" solution.

> Outside of koji, speaking as a kernel developer, people DO boot older
> kernels on newer userlands -- particularly if they are having a
> problem with their hardware.  So it is entirely possible that a
> run-time check for a newly-added syscall is the only way to make
> things work.  :(

I'm afraid you're right.

> That's what people had to do with sendfile(2) for a
> long time.  I imagine most other newly-added Linux syscalls don't find
> their way into core daemons and utilities, so most people don't
> notice.