The image question

Yves de Champlain yves at
Thu Mar 8 16:21:30 PST 2007

Le 07-03-08 à 15:09, Jordan K. Hubbard a écrit :

> On Mar 8, 2007, at 10:05 AM, Daniel J. Luke wrote:
>> The one thing we would loose is the potential for ports to depend  
>> on a specific version of another port that was installed but not  
>> 'active' (ie, you could have multiple versions of some library  
>> port installed with ports that needed each version linked against  
>> the one they wanted without having to change the normal install  
>> layout of that library). I _think_ this is something that jkh has  
>> wanted ever since images were first implemented.
> Amen, bruddah.  It is absolutely one of the biggest wins to staging  
> things through an archive (or depot) and it gets around a problem  
> that may be "corner case" in some respects but also represents one  
> of the most pernicious problems in software husbandry today.  It's  
> sort of akin to the fragile base class problem in C++.  You don't  
> run into it that often, but when you do to any serious extent, it's  
> basically a show-stopper.  You're screwed at that point and every  
> solution is a work-around at best.
> Are we really saying that in the year 2007, we're just going to  
> keep punting on the problem rather than following a good potential  
> solution the rest of the way even though there's short-term pain to  
> be suffered in order to get there?   I know it's a pain in the ass  
> to force ports to point themselves into the depot, but not THAT big  
> of a problem.  There are many ports which are already used to  
> adding a ton of -I and -L lines to attach themselves to multiple  
> dependencies, we just need to do that in a systematic fashion for  
> everything in the dependency list (and add better explicit version  
> information to our deps, which is an accounting win anyway).
> Also, I hasten to point out that even if you're going to be a  
> wussie about solving the n-way dependency problem, archive mode is  
> still useful as an analog to Linux's /etc/alternatives.

Sorry, but I really have a hard time following you here and reading  
this leaves me with a deep feeling of deeply missing the whole point.

I understand that the current image implementation is a step in walk  
to something else that will someday be "the real thing".  Like, for  
example, say "port activate foo" would trigger a mechanism to  
activate the right dependencies and deactivate conflicting ones ?

Of course, I could say that it could also be done with tarballs  
instead of hard links and you could say that I really missed the  
whole  point.  But anyway, my original question was "can someone  
explain ?" rather than "can we dump this crap ?".


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the macports-users mailing list