path normalisation in "base"
Daniel J. Luke
dluke at geeklair.net
Tue Oct 11 06:07:05 PDT 2016
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 <rjvbertin at 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
More information about the macports-dev