[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "mv a b/" when b does not exist

From: Bob Proulx
Subject: Re: "mv a b/" when b does not exist
Date: Wed, 30 Nov 2005 17:32:44 -0700
User-agent: Mutt/1.5.9i

Jim Meyering wrote:
> Paul Eggert <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]