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

[Blair Zajac]

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