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

[Jim Mock]

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