From owner-svn-ports-all@freebsd.org Sun Mar 12 02:10:16 2017 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36136D06E86; Sun, 12 Mar 2017 02:10:16 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0D3D1EBE; Sun, 12 Mar 2017 02:10:15 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by mail.modirum.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cmsxY-0006Am-EA; Sun, 12 Mar 2017 02:10:12 +0000 From: Matthew Rezny To: Adam Weinberger Cc: Tijl Coosemans , 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 Date: Sun, 12 Mar 2017 03:10:09 +0100 Message-ID: <6528743.Wv2563vc2k@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <96D05335-EC74-4CD0-9F00-95CC02B62CF8@adamw.org> References: <201703112115.v2BLF3qk062113@repo.freebsd.org> <1651531.nGg9pBWiG5@workstation.reztek> <96D05335-EC74-4CD0-9F00-95CC02B62CF8@adamw.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 94.142.238.108 X-SA-Exim-Mail-From: rezny@freebsd.org X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:10:16 -0000 On Saturday 11 March 2017 18:30:37 Adam Weinberger wrote: > > On 11 Mar, 2017, at 17:36, Matthew Rezny wrote: > > > > On Sunday 12 March 2017 00:19:58 Tijl Coosemans wrote: > >> On Sat, 11 Mar 2017 21:15:03 +0000 (UTC) Matthew Rezny > >> > >> 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?