On Thu, Jun 12, 2008 at 10:13 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Jun 12, 2008 at 10:03 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Jun 12, 2008 at 3:58 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, Jun 12, 2008 at 10:47 AM, Antonio Huete Jimenez <ahuete.devel@gmail.com> 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