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

[Matthew Rezny]

On Saturday 11 March 2017 18:30:37 Adam Weinberger wrote:
> > 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

It may well be that gnome.mk needs some work, but from what I've seen it is 
much more expansive. Looking back it was April 2016 when I submitted an update 
to a port using wxgtk and the committer added the pile of gnome libs I had 
been ignoring for some time by then, so maybe it has been a whole year now. I 
had asked on IRC if those were really correct or if gnome needed fixing in some 
way and the answer was that all those things suggested by stage-qa should be 
added. Some time after, a PR was opened against once of my ports which uses 
Qt, saying that I needed to add bunch of a number of Xorg dependencies. stage-
qa did suggest those, although it hadn't the last time that port was updated 
before then, so I got confirmation and then went ahead and added them despite 
thinking "what happens when someone builds QT for Wayland instead of X?" the 
whole time. I suppose the same question pertains to GTK3.

It is not just the big GUI libraries that might need something more in their 
respective Mk files. Many ports that use gnutls produce warnings from stage-qa 
because gnutls depends on libgcrypt which depends on libgpg-error, and while I 
sometime see libgcrypt alongside gnutls, I rarely notice libgpg-error 
alongside either, and I find myself frequently adding both. Those are just an 
example of a simple and common dependency chain that stage-qa complains about. 
Should every port using libgcrypt have to depend on libgpg-error when 
libgcrypt already depends on it, or is the stage-qa check over aggressive? 
Should every port using nss have to also explicitly depend on nspr because nss 
does?

A couple weeks ago I opened PR 217311 for both those issues and more in 
bitlbee. Are the additions correct, or is stage-qa wrong?