Date: Sun, 12 Mar 2017 16:36:45 +0100 From: Tijl Coosemans <tijl@FreeBSD.org> To: Matthew Rezny <rezny@freebsd.org> Cc: Adam Weinberger <adamw@adamw.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, swills@freebsd.org, gnome@freebsd.org Subject: Re: svn commit: r435961 - in head/www/webkit-gtk2: . files Message-ID: <20170312163645.38eeaa55@kalimero.tijl.coosemans.org> In-Reply-To: <6528743.Wv2563vc2k@workstation.reztek> References: <201703112115.v2BLF3qk062113@repo.freebsd.org> <1651531.nGg9pBWiG5@workstation.reztek> <96D05335-EC74-4CD0-9F00-95CC02B62CF8@adamw.org> <6528743.Wv2563vc2k@workstation.reztek>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Mar 2017 03:10:09 +0100 Matthew Rezny <rezny@freebsd.org> wrote: > On Saturday 11 March 2017 18:30:37 Adam Weinberger wrote: >> On 11 Mar, 2017, at 17:36, Matthew Rezny <rezny@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@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. >>> >>> 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. If people told you to list indirect dependencies that is incorrect, but the stage-qa script isn't wrong either. While listing indirect dependencies is bad, relying on other ports to pull in direct dependencies is also bad (for the same reasons: those other ports can change). The stage-qa script scans programs and libraries for their dependencies (DT_NEEDED tags) and warns if any are missing from LIB_DEPENDS because these are potentially direct dependencies. This can result in false positives and perhaps the message printed by stage-qa should make this more clear and that it's not good to add them simply to silence the warning. >> 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. > > 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. The reason programs and libraries may be linking to indirect dependencies is because *-config scripts or pkg-config files of direct dependencies said so. For instance "pkgconf --libs glib-2.0" returns "-L/usr/local/lib -lglib-2.0 -lintl" which causes everything that needs libglib to link to libintl as well. This may be wrong and then the *-config scripts need to be patched to remove the extra libraries, but often this is correct. The libglib headers include libintl headers and define macros and inline functions that call libintl functions. Code that includes libglib headers can end up calling libintl functions and thus must be linked with libintl. I think it's best to create or fix existing USES for cases like this. Antoine recently did this for libglib and libintl. > 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? Gnutls does not depend on libgcrypt or libgpg-error. It did in the past and some upstreams may have added a search for libgcrypt to their configure scripts instead of relying on the output of "gnutls-config --libs" or "pkgconf --libs gnutls". It's an example of why listing indirect dependencies is bad. Gnutls changed and their configure scripts are pulling in unneeded dependencies now and need to be patched. For the case of libgcrypt needing libgpg-error I suggest we create a USES=libgcrypt. Libgcrypt headers include libgpg-error headers. > 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? You can probably answer this yourself now :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170312163645.38eeaa55>