[pacman-dev] [PATCH] Remove -f option from ln for POSIX compliance (close FS#24893)

[Allan McRae]

On 27/06/11 06:07, Dan McGee wrote:
> On Sun, Jun 26, 2011 at 2:57 PM, Eric Bélanger<snowmaniscool at gmail.com>  wrote:
>> On Sun, Jun 26, 2011 at 3:46 PM, Dan McGee<dpmcgee at gmail.com>  wrote:
>>> On Sun, Jun 26, 2011 at 2:13 PM, Eric Bélanger<snowmaniscool at gmail.com>  wrote:
>>>
>>> Looks mostly good, only one comment below.
>>>
>>> d>  Signed-off-by: Eric Bélanger<snowmaniscool at gmail.com>
>>>> ---
>>>>   scripts/makepkg.sh.in  |   18 ++++++++++++------
>>>>   scripts/repo-add.sh.in |   10 ++++++----
>>>>   2 files changed, 18 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
>>>> index 8d082a2..ed5cdef 100644
>>>> --- a/scripts/makepkg.sh.in
>>>> +++ b/scripts/makepkg.sh.in
>>>> @@ -518,7 +518,8 @@ download_sources() {
>>>>                 local file=$(get_filepath "$netfile" || true)
>>>>                 if [[ -n "$file" ]]; then
>>>>                         msg2 "$(gettext "Found %s")" "${file##*/}"
>>>> -                       ln -sf "$file" "$srcdir/"
>>>> +                       rm -f "$srcdir/$file"
>>>> +                       ln -s "$file" "$srcdir/"
>>> Is this behavior (specifying a directory for the link name)
>>> POSIX-compliant or guaranteed by anything except GNU ls?
>>
>> No idea. It was already used in another place in makepkg.sh.in so I
>> supposed that it was OK. If you want, I can resent the patch with the
>> link name specified.
>
> Well looking around, this whole bug report is a bit of BS, although we
> can easily work around this. -s and -f are both mandatory in the
> "latest", as of 2003, spec. [1] The same spec also indicates that this
> "target_dir" vs. "target_file" behavior is completely OK, so no need
> to fix this up unless we actually see problems in the wild.
>
> -Dan
>
> [1] http://www.unix.com/man-page/posix/1posix/ln/
>

I'll ack the patch as is.  Removing the "-f" usage in ln is a small 
burden if we have people who actually want to use old shitty versions of 
these tools.  Any further issues can be fixed later (preferably by the 
people experiencing the problems).

Allan