Ticket #14796 (pike): please commit

[Eric Hall]

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

	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.

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

	Is it really that hard?  Its non-trivial, that's clear, but is
it something larger than a GSoC person could tackle?  Or should an item
like this be added to the design scope of a new dependency engine?  It
certainly seems like a very worthy feature to me.


		-eric