On Thu, Jun 12, 2008 at 10:13 AM, Dan McGee <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 10:03 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote: >> On Thu, Jun 12, 2008 at 3:58 AM, Xavier <[EMAIL PROTECTED]> wrote: >>> On Thu, Jun 12, 2008 at 10:47 AM, Antonio Huete Jimenez >>> <[EMAIL PROTECTED]> wrote: >>>> In repo-add/repo-remove, readlink is used to calculate the full path of >>>> a file (canonicalize with option -f). But in BSD there's no such option >>>> in readlink, so you have to use realpath instead >>>> >>> >>> Sorry, I didn't realize my question was that obscure, let me rephrase it : >>> Why the hell do we need to calculate the full path of these files? >>> >>> If I ask that question, it is because I am personally not able to >>> answer it myself after looking at this repo-add script. >>> If someone can explain why this is necessary, then we will have to use >>> your readlink/realpath patch. >>> If no one can, then it is probably useless so we can remove readlink >>> usage altogether and solve this portability problem in a much simpler >>> way. >> >> Without looking at the script, I imagine it has to do with calculating >> the path used in %FILENAME% in the db entries. it *does* support full >> paths: >> %FILENAME% >> foo/bar/somepkg-1.0.pkg.tar.gz > > That doesn't even use the result of readlink, haha: > local pkgfile=$(readlink -f "$1") > ..... > echo -e "%FILENAME%\n$(basename "$1")\n" >>desc > > So FILENAME doesn't support any full paths- this has come up on the > list before. I really see little need for this readlink usage, but > Aaron, you did include it originally. If you get a chance to look > closer, let us know what you think it may have been for.
Well if it's not done that way then it's possible I intended to do it that way and just forgot. The only time I used readlink in scripts is when I need to create a relative path from a to b (or, when I need an absolute path). So, the options are either: a) keep readlink there and allow full paths b) remove it entirely I kinda like the idea of using full paths, but it's not a huge deal _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
