Explicit vs Implicit deps [was Re: Unstated dependencies on gettext]

[Kevin Ballard]

I would say if a port depends directly on another port, it should  
list that dependency, even if one of its other dependencies also has  
this. As you pointed out, this is more robust to change. And the  
notational trick you mentioned for things like GNOME or KDE would  
also help with the dependency explosion problem.

But anything a port doesn't use explicitly probably shouldn't be  
listed. For example, glib2 depends on gettext. So if my port Barfoo  
uses glib2, it indirectly depends on gettext, but if it doesn't  
actually use anything from gettext directly, it should leave that  
dependency to get resolved hierarchically via glib2.

So basically, I'm in favor of a flatter hierarchy. But, were I given  
the power to decide, I'd still be hesitant about committing to this,  
because I can see the cons of flat and benefits of hierarchical too.

On Dec 28, 2006, at 9:31 PM, Jordan K. Hubbard wrote:

> This brings up an interesting(?) point that, if memory serves me  
> correctly, we've discussed before without resolution.
>
> First, I'll sum up the previous discussions with what I believe to  
> be the essential underlying question:  Are dependencies best  
> described (in a complex software collection) as hierarchical or flat?
>
> Hierarchical has its obvious advantages:  You avoid the  
> combinatorial explosion of dependencies that things like GNOME and  
> KDE would drag in to each and every KDE clock or GNOME mp3 tag  
> editor port and, notionally at least, you can have a much smaller  
> collection of ports contain the "authoritative dependency lists"  
> for commonly used crap and, presumably, a smaller number of things  
> to edit when those dependencies change.
>
> On the flip side, flat has other advantages:  It decouples ports  
> from one another, particularly in a system like MacPorts where you  
> don't actually get full benefit from those "common ports" since  
> once one of them is installed, its dependency list is statically  
> determined at install time and ages thereafter.  Even if the  
> Portfile gets updated to track new deps, it doesn't matter if the  
> user has already built and installed the port given the short- 
> circuiting that will then take place, avoiding the updated  
> Portfile.   Flat also copes better with other types of dynamism in  
> the collection - say gettext depends on libintl for a few years,  
> then one day somebody realizes that gettext only needs a few  
> functions from libintl and would be better off implementing those  
> functions itself, so they do this in the next release of gettext.   
> The Portfile maintainer for gettext realizes this and removes the  
> libintl dependency.  Boom, all those ports which depended on  
> gettext with the assumption that they'd get libintl for free now  
> break.   Finally, a flat dep space lends itself well to automation  
> - if kvv ever implements something similar to DarwinBuild for  
> MacPorts, that mechanism will find every single port something  
> depends on and, presumably, update the Portfile accordingly.  At  
> that point, the hierarchy becomes flattened anyway.
>
> Despite having a lot more verbiage on the subject of flat  
> dependencies, I don't actually have a firm preference for either -  
> I can still see both sides of the argument fairly clearly.
>
> Thoughts?

-- 
Kevin Ballard
http://kevin.sb.org
kevin at sb.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20061228/fec7120d/attachment.html