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