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 <[email protected]> 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 [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
