On Tuesday October 11 2016 09:07:05 Daniel J. Luke wrote: >https://lists.macosforge.org/pipermail/macports-dev/2014-May/026728.html >which I linked to the last time you brought this up.
Funny (not so), I can't remember that at all... I used to have a similar configuration, but have since gone back to hiding the fact that /opt/local is a symlink completely - without ill effect as far as I can tell. In fact, without almost any effect at all; the paths recorded in my log files still reflect the actual location of wherever my build directory lives. >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). Well yes, that much is clear by now. We'll see if that's the same when the question is brought up in a more general context, as I tried to do here. I *am* currently testing a very simple change to action_provides which works for me and should not introduce any side-effects on standard configurations if my assumption is correct that files are registered as they appear under `port work foo`/destroot . I'm more than willing to submit the change, but it's also very tempting to keep it just for myself there appears to be no interest. Looking a bit harder at what [file normalize] does, it seems that it only touches elements in the path, not the final file or directory name. The idea is probably that get the owner of the file even if you query that particular file through a symlink. There's sense to that. There are basically 3 ways we could change this (I'll leave it in the middle whether that's an improvement or not): - use the normalised path ($file) for the checks but the original $filename for the final registry lookup - add an option to `port provides` that deactivates the whole normalisation step (with the idea that maybe there are other use-cases than a symlinked $prefix) - normalise the path but restore the actual prefix as it's defined in macports.conf that latter option could actually be implemented as a PacPorts library function to replace [file normalize]. But that raises the question again: what are the current reasons for normalising, and what would break if the prefix isn't normalised (and that leads to a different result)? R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
