Ticket #14796 (pike): please commit

Jordan K. Hubbard jkh at apple.com
Tue Apr 1 02:02:57 PDT 2008

On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote:

> Maybe I'm too ignorant, but isn't also the fact that dependencies  
> are version-agnostic one major cause of build fails and probably a  
> cost-effective gain to change?

Not ignorant at all, yes, this is a well-known shortcoming of  
dependencies.  No way to specify minimum version, maximum version,  
range of versions, and so on.  Package systems like RPM do, but  
lacking this in the base system means MacPorts can't make more  
intelligent dependency decisions and it can't pass those on to the  
packaging system, which will need to make the same decision if the  
user uses packages to install instead.  I think "new dependency  
engine" has even been on the task list for for several years now.

> I'm rather new to macports, but I was delighted to find that it can  
> keep multiple versions installed, with only a single one active  
> (usually) -- only to learn later then that it is otherwise not using  
> this feature, really.

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.

To be fair, and make no mistake, it's actually pretty hard to get this  
right.  Smashing everything together in a common $prefix and assuming  
that all your deps are part of $prefix at any given time is a hugely  
simplifying assumption, too.  For most ports, a simple -I${prefix}/ 
include and -L${prefix}/lib is all the stands between their vanilla  
state and working properly with MacPorts.  In a true multiple-version  
world, each and every dependency potentially adds to the search paths.

- Jordan

More information about the macports-dev mailing list