On 2016-10-11 16:38, René J.V. Bertin wrote:
> This does work though:
>
> {{{
> proc macports::normalize { filename } {
> # normalise the user-specified prefix. The test file under $prefix need
> not exist for that:
> set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
> set file [file normalize $filename]
> # check if the result starts with the "normalised" prefix:
> if {$nprefix ne $macports::prefix && [string first $nprefix $file] eq 0} {
> # obtain the part after the normalised prefix, and prepend the
> user-specific prefix to it:
> set file [file join $macports::prefix [string range $file [string
> length $nprefix]+1 end]]
> }
> return $file
> }
> }}}
This might solve the ${prefix} being a symlink. Do we want to treat that
as a supported special case after all?
If ${prefix}/bin is a symlink, this would still not work as expected.
How do we decide when to honor a symlink put in place by a port versus
ignoring a manual replacement in normalization? At which paths do we
want to support symlinks?
We make certain assumptions about ${prefix}, such as the common check
for [file writable ${prefix}] throughout the code. We should make sure
these always follow the symlink and not report status of the symlink
itself. Symlinks have their own permission bits on HFS+, can be changed
by chmod -h and will adopt umask on creation.
Rainer
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
