On 02/04/2011 09:07 AM, Krzysztof Żelechowski wrote: > I know exactly which implementation of mv will be used.
Not necessarily. The point of open source is that someone can copy your
scripts into their setup, which might be different than yours.
>
>> Since POSIX already says you have to be
>> prepared for failure, the best you can do is to instead rewrite your
>> openSUSE scripts to not fail in the first place by doing a preparatory
>> check, and rewriting 'mv lib %{_lib}' into 'test %{_lib} != lib && mv
>> lib %{_lib}', so that you will work regardless of whether coreutils
>> changes behavior, or even whether you are using coreutils' mv.
>>
>
> I actually used code like
> [[ -d '%{_lib}' ]] || …
> but it is not 100% proof because it creates a race condition.
Several things to think about:
1. Is that race condition ever likely to be lost? That is, if someone
is simultaneously messing with /usr/lib (or /usr/lib64) while your
package is trying to install there, that system already has much more
serious problems.
2. That code snippet is bash-specific.
3. What's wrong with textual comparison (as I suggested), which avoids
the race between probing the system and actually trying to perform a rename?
At any rate, I don't see any reason for coreutils to change its
behavior; although I might be persuaded otherwise if someone writes up a
patch (including testsuite and documentation), and in particular, you
MUST ensure that coreutils does NOT regress on:
ln a b
mv a b
which uses behavior 3 permitted by POSIX (silently unlink a, reducing
the hard link count of b by 1).
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
