Ticket #14796 (pike): please commit

[Jordan K. Hubbard]

I think we must be talking about a different mechanism since in what  
I'm suggesting, the embedded paths WOULD point to the appropriate  
depot locations, the install_name of the libs WOULD be the target  
locations and applications absolutely WOULD look for their resources  
in the depot locations.  There are no technical reasons why this  
wouldn't be possible and, as someone else recently pointed out, the  
GoboLinux* folks have certainly managed to do it.

The only function of /opt/local in that scenario would be as a link  
farm to activated applications in the depot so that users did not have  
to adjust their $PATH to contain a path to each and every /opt/local/ 
var/macports/software/foo/bar/bin directory (though, frankly, if there  
were some sort of path-helper tool to set that, one could potentially  
retire /opt/local entirely and dispense with the activated/deactivated  
state, but that's probably too ambitious to start with).

- Jordan

* http://www.gobolinux.org/?page=at_a_glance is interesting reading.   
It makes me glad to see that at least some folks have been willing to  
tackle this in such a systematic way and, if they get the whole "per- 
dependency-tree namespace" stuff ironed out, will definitely have  
achieved something impressive here.

On Apr 2, 2008, at 3:44 PM, Peter O'Gorman wrote:

> It does not solve all that much, as all the embedded paths are still
> /opt/local, the install_name of the libs is still /opt/local,
> applications will still look for resources in /opt/local, they will  
> not
> look in the depot.
>
> Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in  
> the
> depot will have absolutely no effect on the resulting binary, making
> such a change, imo, pointless, older versions of things will still be
> broken when you update some dependency.