The image question

[Jordan K. Hubbard]

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.

> It seems to me like this just exponentially increases the installed  
> system complexities and in the few cases where it would be very  
> useful to have multiple different library versions installed, it  
> makes more sense to me to alter the port so they can both be  
> installed at the same time (like the db43/db44 ports, for example).

If you could always do that, I'd agree with you.  Unfortunately, you  
can't.  Take the example of tcl in the FreeBSD ports collection, at  
the "high point" of which there were at least 4 simultaneous versions  
(all API incompatible with one another) in the tree.  They couldn't  
solve it without breaking tclsh*, so they broke tclsh, there wasn't  
any way to alter the tcl ports in such a way that you could have n  
versions and a working tclsh.   This is just one example and there  
were others encountered during the history of FreeBSD's (much bigger)  
ports collection.   That's why I'm such a die-hard (translation:  
annoying dickhead) about solving such problems architecturally rather  
than by band-aiding individual instances as they come up and  
suffering what seems like much less pain at the time.  I have plenty  
of hard-won (and equally painful) evidence that this only works for  
so long and once you get to 10,000 or more ports, the number of  
accumulated band-aids grows so large as to constitute a serious  
maintenance problem and everyone is jumping up and down saying "why  
didn't you short-sighted f**kers just do this right in the first  
place?!  Now it's too late to clean up your mess!!"

- Jordan

* Rather than work, tclsh emitted a diagnostic saying "please invoke  
a specific version of tclsh", something which may have been  
informative to developers but hosed end-users who didn't even know  
their application or script was trying to use tclsh at all, simply  
that it crashed with some weird diagnostic rather than actually  
function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20070308/21d6695b/attachment.html