[pacman-dev] [PATCH] makepkg: canonicalize paths from environmental variables

[Allan McRae]

On 30/09/10 21:26, Xavier wrote:
>>
>> Well, one way to avoid all this is to add something like:
>>
>> [[ $PKGDIR == "." ]]&&  $PKGDIR="$startdir"
>>
>> before we preserve the environmental variables.   But that is bad as
>> things like PKGDIR="../" would still cause issues.
>>
>
> I rather meant a way to remove any assumption of PKGDEST being absolute.
>
> This is the only broken code, isn't it :
>
> if (( ! ret ))&&  [[ "$PKGDEST" != "${startdir}" ]]; then
>    ln -sf "${pkg_file}" "${pkg_file/$PKGDEST/$startdir}"
>    ret=$?
> fi

No.  It also affects the location of the tarfile.   e.g. PKGDEST="." 
puts the tar file in $pkgdir because we create the tarball location 
using $PKGDEST while in $pkgdir:

cd $pkgdir
...
pkg_file="$PKGDEST/${nameofpkg}-${pkgver}-${pkgrel}-${PKGARCH}${PKGEXT}"
...

> Why not do something like :
>    local link_file="$startdir/${nameofpkg}-${pkgver}-${pkgrel}-${PKGARCH}${PKGEXT}"
>    if [[ ! -f "$link_file" ]]; then
>      ln -sf $pkg_file $link_file
>    fi
>
> I don't know if there are cases where a regular file exists but is not the
> package we just built. If it can happen and we care, we could try to test
> whether pkg_file and link_file are not actually the same regular file.

Hmm...  we check if the package exist before building but do we check 
both PKGDEST and $startdir?  We probably should.

>> So I think we should just add the bash implementation of realpath as
>> a function inside makepkg.  The one at stackoverflow is very
>> simplistic so I will take another look at the one posted to the
>> mailing list.  We should really look at libifying some/all of this
>> sort of stuff out of makepkg...
>>
>
> Btw there are actually several bash impl in that link, the last one is more
> complex :
> http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac/2710477#2710477
>

Ah - I had missed that.  That is definitely the best implementation I 
have seen so far.  Although the dereferencing the symlink is simpler / 
more efficient in the one posted on this mailing list.  Some combination 
might be fine.

Allan