Ticket #14796 (pike): please commit

[James Berry]

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

> 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.

I also worry about cases like when A links against B and C. B was  
linked against D.version1 while C was linked against D.version2. Thus  
when A loads, it pulls in two (?) potentially incompatible versions of  
D?

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2761 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080402/d73358a2/smime.bin