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
[EMAIL PROTECTED]
http://www.tildesoft.com
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
