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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
