Jim Meyering wrote: > Paul Eggert <[EMAIL PROTECTED]> wrote: > >> I also would favor (B). But we certainly need testsuite additions to > >> ensure that we don't introduce future regressions against this decision. > > > > OK, it'll be harder to test (B), since that relies on the test suite > > knowing what rename() does. But I guess we can work around that. > > It shouldn't be hard. > Just run a little perl snippet to determine what rename() does, > and base the expected results on that.
A problem exists with configure testing for kernel behavior and then freezing that into the code. If configure determines a certain kernel behavior and then a new kernel is booted with different behavior then the configuration is out of date. Upgrading the kernel would then require a program upgrade at the same time. Better when practical to perform a runtime test. (Maybe require is too strong of a word for the behavior we are talking about here but you get the idea.) It is common to upgrade kernels over time or to boot different kernels at different times or to build on one system for another system. I think it is best to avoid attaching direct dependencies upon the kernel. Okay to just pass the problem upstream to the kernel and if the rename succeeds or fails then so be it. But second guessing will probably get in trouble at times. Here are some common use questions. If I compile on a linux-2.4 kernel should I expect the result to work on a linux-2.6 kernel? I think most people would expect most things to work. Especially small targeted essential utilities like 'mv'. How about compiling on a linux-2.6 kernel but then downgrading the kernel to linux-2.4 for other reasons? Should the result work on a linux-2.4 system? How about compiling in a chroot on a linux-2.6 kernel to compile against the stable libc? Again I think most people would expect the result to work. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
