Re: Koji build failure with coreutils-7.5

[Jeff Garzik <jgarzik pobox com>]

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