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