one way to handle it could be:
% svn diff
Index: port.tcl
===================================================================
--- port.tcl (revision 153771)
+++ port.tcl (working copy)
@@ -2389,7 +2389,12 @@
return 1
}
foreach filename $portlist {
- set file [file normalize $filename]
+ # don't normalize absolute paths
+ if {"/" ne [string index $filename 0]} {
+ set file [file normalize $filename]
+ } else {
+ set file $filename
+ }
if {[file exists $file] || ![catch {file type $file}]} {
if {![file isdirectory $file] || [file type $file] eq "link"} {
set port [registry::file_registered $file]
Before -
% port provides `which nmap`
/Volumes/Data/opt/local/bin/nmap is not provided by a MacPorts port.
After -
% port provides `which nmap`
/opt/local/bin/nmap is provided by: nmap
> On Oct 11, 2016, at 9:07 AM, Daniel J. Luke <dl...@geeklair.net> wrote:
> see also:
>
> https://lists.macosforge.org/pipermail/macports-dev/2014-May/026728.html
>
> which I linked to the last time you brought this up.
>
> (no one replied to that original post).
>
> I expect no regular base contributor cares enough about that unsupported
> configuration to work on it - which means someone who does care (you,
> perhaps?) needs to generate and test a change that can be incorporated
> (otherwise we'll just keep having this conversation every year or so).
>
> On Oct 11, 2016, at 4:43 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
>> I'd like to understand a bit better why the base layer does path
>> normalisation in a number of places where its use isn't immediately obvious
>> to me, like for instance the action_provides procedure in the port script.
>> If that's not so broad of a question that it cannot be answered with a
>> single, succinct explanation.
>>
>> I can see how it would probably be required in a sandboxing context, and I
>> have no idea exactly what kind of sandboxing MacPorts does. (I do seem to
>> recall whatever issues it had with e.g. a symlinked $prefix were resolved a
>> while ago.)
>>
>> To come back to action_provides: if the registry saves a port's "intended"
>> paths (the ones stored in the software image tarball), why do a lookup of
>> the actual/resolved path? That would make it impossible to check which port
>> installs a symlink (to a file or directory installed by itself, some other
>> port, or even to something in system space), regardless of whether there are
>> "unexpected" symlinks in the path, no?
--
Daniel J. Luke
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
