If it weren't for the giant pain of trying to track down all inherited dependencies for a given port (particularly ones with a pretty large list), I think I'd lean more towards the flat dependencies since we'd probably be less likely to run into breakage due to a missing dependency somewhere (helping with automation is also good). That said, I think it'd be more fun to poke myself in the eyeballs with a stick than try to track down the dependencies for a few of my ports (gtk2 and some ports that use it come to mind immediately). I guess I'm not sure which I'd choose either if I had to decide. Do we go with easier maintenance or (potentially) better reliability? Ugh. - jim On Dec 28, 2006, at 6: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?

- Jordan

On Dec 28, 2006, at 5:28 PM, Jim Mock wrote:

...

Crap, ignore that, I had it backwards. The gettext port actually depends on libiconv and not the other way around.

If you do come across things that link against libintl and don't have gettext as a dependency (whether direct or indirect), it should probably be added as one.

- jim

On Dec 28, 2006, at 5:24 PM, Jim Mock wrote:

...

On Dec 28, 2006, at 5:00 PM, Kevin Ballard wrote:

...

After having updated gettext, I'm finding a number of ports that are linking against libintl (provided by gettext) but don't declare a dependency on gettext.

For example, gsed links against libiconv, but doesn't declare a dependency on gettext.

This is because libiconv depends on gettext so, if you've got libiconv, you've got gettext.

...

The question I have is, would some of these ports have worked if gettext wasn't installed, but just happen to link against libintl for extra functionality if it's there?

It should because something it depends on depends on gettext (whether it be libiconv or something else).

- jim

_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev