Using utimensat in fs_entry.cc breaks support for Linux < 2.6.22

[jorrit]

I am unfortunately stuck at an old kernel version for the moment. I updated Paludis to 0.44.1, and suddenly no package could be installed anymore. All installs fail with:

  * When setting utime for '<somefile>':
  * utime '<somefile>' failed: Function not implemented (paludis::FSError)

When looking in the source (fs_entry.cc) it appears that since Januari 2nd, 2010, utimensat is used instead of utime. I'm not an expert in kernel programming or C++ programming and it seems strange to me that Paludis 0.44.1 even compiled correctly while one of the functions it calls does not exist, but apparently it is possible and I'm stuck with a Paludis version that can't do anything.

[ingmar]

it seems strange to me that Paludis 0.44.1 even compiled correctly while one of the functions it calls does not exist, but apparently it is possible and I'm stuck with a Paludis version that can't do anything.

That sounds like you're using linux kernel headers newer than the kernel you're running.

[jorrit]

That is the case, which would explain this behaviour. So paludis should not have compiled on my machine. I however can't find any mention of the minimum kernel version requirement and I think it's odd to alter the minimum kernel requirements in a minor release. But I'll leave it to the paludis maintainers to evaluate this.

[ingmar]

The minimum requirement didn't change, when building aginst older kernels we don't use utimensat.

[filko_]

To be more precise: you are not building against the running kernel, but installed kernel headers, and its user's job for them to more or less match in version. If you want paludis to work with old kernel -- compile it against old headers. What you did is very similar to upgrading only header files in a library and being surprised package compiled against those headers doesn't work with unupgraded .so files.

[jorrit]

I know the mismatch is my mistake. I'm just curious as to what would have happened if I compiled it with the right headers.

[jorrit]

Sorryy - Ingmar answered that question. Thanks a lot!

[dleverton]

Actually we can handle this easily enough

[dleverton]

Yoink

[dleverton]

Fixed in 990c3d22ab79a76d6610f65df63efc14a1167300