Ticket #14796 (pike): please commit

[Peter O'Gorman]

Eric Hall wrote:
> On Tue, Apr 01, 2008 at 02:02:57AM -0700, Jordan K. Hubbard wrote:
>> On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote:

>> This is sadly somewhat controversial.  I think dependencies should  
>> definitely be directed at the depot location, e.g. something that  
>> links with, say, jpeg version 6.2, shouldn't link to /usr/lib/libjpeg. 
>> 62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ 
>> local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- 
>> path dependencies.  Then whether something is "active" or not has  
>> nothing to do with whether it can be depended on.  Every time the  
>> subject comes up, however, various people rapidly get the creeping  
>> crawlies and we lose the courage to actually attempt this.
> 
> 	I've always thought this was an excellent idea, it neatly
> solves conflicting version problems (libnet for example) and allows
> a new version of $THIS_DEPENDENCY to be installed without breaking
> $OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY,
> and/or resulting in the massive rebuild fsck to bring everything back
> to happyness when a dependency is upgraded.

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.

Peter
-- 
Peter O'Gorman
http://pogma.com