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