svn commit: r435961 - in head/www/webkit-gtk2: . files

[Adam Weinberger]

> On 11 Mar, 2017, at 17:36, Matthew Rezny <rezny at freebsd.org> wrote:
> 
> On Sunday 12 March 2017 00:19:58 Tijl Coosemans wrote:
>> On Sat, 11 Mar 2017 21:15:03 +0000 (UTC) Matthew Rezny
>> 
>> <rezny at FreeBSD.org> wrote:
>>> Author: rezny
>>> Date: Sat Mar 11 21:15:03 2017
>>> New Revision: 435961
>>> URL: https://svnweb.freebsd.org/changeset/ports/435961
>>> 
>>> Log:
>>>  - Fix building on PPC/PPC64 [1]
>>>  - Fix building on ARMv6 [2]
>>>  - Add missing indirect dependencies
>> 
>> You should never add the dependencies of another port to your port
>> because if that other port ever changes dependencies your port will still
>> pull them in.  If you are getting warnings about missing dependencies and
>> you know they are indirect then you know there's a problem with one of
>> the other dependencies of your port.  The problem needs to fixed there.
>> In this case it's probably because of gnome related pkg-config files.
>> These dependencies need to be added to Mk/Uses/gnome.mk.
>> 
>>>  - Possibly fix build on sparc64 (unconfirmed)
>>> 
>>>  PR:	212903 [1]
>>>  Submitted by:	jhibbits [1], strejda [2]
>>>  Approved by:	swills (mentor)
> 
> I completely agree with that from a technical position. When stage-qa started 
> complaining about indirect dependencies, I initially ignored them as it looked 
> like an obvious error in the script. Surely, actual dependencies can be 
> calculated recursively taking options into account. However, through both the 
> actions taken on the PRs submitted at the time and direct statements when I 
> questioned the situation, I was informed that the indirect dependencies should 
> be added. I think it is completely unproductive and incorrect, but I had more 
> important things to do than press the issue.  I would be happy to cease adding 
> indirect dependencies, which not only depend on the port's options but the 
> options of the ports it depends upon, and the options of the ports those 
> depend upon and so on. Has there been a change of policy and if so when can we 
> expect to see a fixed stage-qa? It'll take some time to undo all the damage.

The policy is that dependencies need to be listed; that clearly hasn't changed. Is there any indication that stage-qa is broken? Tijl is completely correct, if the problem is that Uses/gnome.mk isn't listing all its dependencies, then it needs to be fixed, not stage-qa.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org