On Sun, Jun 26, 2011 at 2:57 PM, Eric Bélanger <[email protected]> wrote: > On Sun, Jun 26, 2011 at 3:46 PM, Dan McGee <[email protected]> wrote: >> On Sun, Jun 26, 2011 at 2:13 PM, Eric Bélanger <[email protected]> >> wrote: >> >> Looks mostly good, only one comment below. >> >> d> Signed-off-by: Eric Bélanger <[email protected]> >>> --- >>> 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/
