[52497] trunk/dports/gnome/liboobs/Portfile

[nox]

Le 17 juin 09 à 22:10, Blair Zajac a écrit :

> David Evans wrote:
>> nox wrote:
>>> Le 17 juin 09 à 21:09, Joshua Root a écrit :
>>>
>>>> On 2009-6-18 05:07, nox wrote:
>>>>> So liboobs does not depend anymore on glib2 and gettext?
>>>>> Or did you just remove them because dbus-glib depends on them?  
>>>>> If this
>>>>> is the answer, you should not do that.
>>>>
>>>> Why not? If every gnome component declared a dependency on  
>>>> everything it
>>>> links against, the list would be huge.
>>>>
>>>> - Josh
>>>
>>> I agree with you in the case where it just links against it  
>>> because one of its dependencies need it.
>>> But if the port checks explicitely for a library in its configure  
>>> script or uses one of its functions
>>> in the sources, then it should be listed as a dependency.
>>>
>>> _______________________________________________
>>> macports-dev mailing list
>>> macports-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>>
>> I agree with Josh on this.  The list of redundant dependencies is  
>> huge as it it.
>> There's really no need to declare this dependency when it is clear  
>> dbus-glib depends on it and that isn't likely to
>> change soon.  In addition, it helps to reduce  the number of  
>> instances where it is necessary to use a path dependency
>> to enable the use of glib2-devel, simplifying over-all port  
>> maintenance.
>> Similarly, I advocate not declaring pango or cairo (or glib2 for  
>> that matter) if gtk2 is a dependency on similar grounds.
>> Another good example is gettext which is used by almost every gtk  
>> dependent and declared in many and is declared as a dependency in  
>> glib2.
>> I think your rule is a bit too strong.  If the configure test is  
>> for the existence per se of a particular dependency then I agree it  
>> should be
>> included.  But in this case the test is not to see if glib2 exists  
>> but to see if it satisfies a certain minimum version requirement  
>> which we satisfy.
>> In any case, if you really feel strongly about this particular  
>> case, please feel free to change it.
>
> I'm with Dave on this one.
>
> We recently ran into this with serf and its dependence upon apr and  
> apr-util, which pulls in SQLite, PostgreSQL and BerkeleyDB  
> dependencies depending upon the variants it was built with.  Having  
> to have serf have the same variants as apr and apr-util just to get  
> those port dependencies isn't something I wanted to manage, so I  
> just kept the dependencies on apr and apr-util.
>
> Blair

I don't see what is wrong in declaring only apr and apr-util, as I  
doubt serf calls SQLite, PostgreSQL or BerkeleyDB functions directly.  
See my previous mail.