From owner-freebsd-ports@FreeBSD.ORG Fri Jun 4 19:59:08 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 016711065675 for ; Fri, 4 Jun 2010 19:59:08 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC548FC1E for ; Fri, 4 Jun 2010 19:59:07 +0000 (UTC) Received: by wyf28 with SMTP id 28so1527573wyf.13 for ; Fri, 04 Jun 2010 12:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=9hdeqo4xm08lacs67JDYa8Y7IGH3Q+GMgrc+lMnLvj8=; b=ANrtYEC+o/kCIpnYI/EtGqwJIXvl7DVGNTQt7cvDRid6mgjIm13jYOqsai3rNCBgC6 WPxYXBMAgCb/3tGkUWIuk/DjXCbBj0P6XOlLxflK7OgWTCd15Do6Tm0le9/EgFl/luAN uljnkiy1q4WyL6PXcghvT1yBbiiPzDg25KXtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=brdBTocKGeGDw3t1Pb6x1LI6pvwy6PZcuawMc4QiF7ECdExNmCh8c30ePuKLmHF9z3 nXWMcA0eGeZS/CTajzbW8LsvQyQdiiRzgcQ1LZQoRGxwoRN4L4RFvV+LAoqo98Yh2RbH Pd4CEmN2rI9MXNf8wwygC8F6pQZgFh8esbJRI= MIME-Version: 1.0 Received: by 10.216.85.74 with SMTP id t52mr1048946wee.99.1275681544214; Fri, 04 Jun 2010 12:59:04 -0700 (PDT) Received: by 10.216.183.5 with HTTP; Fri, 4 Jun 2010 12:59:03 -0700 (PDT) Date: Fri, 4 Jun 2010 19:59:03 +0000 Message-ID: From: "b. f." To: Jan Henrik Sylvester Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org Subject: Re: Direct or indirect libdependencies (using the libintl.so.8 case) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 19:59:08 -0000 >Thus, explicit_lib_depends.sh cannot be relied upon what to rebuild, >either -- it missed the same that libchk does. Anyhow, this does not >matter at all to the main point I tried to raise: > Maybe the specific results that you mentioned don't matter, but the fact that these programs fail to obtain satisfactory results in real cases, due to some of the complicating factors Alexander mentioned, _does_ matter -- because if there were a cheap, foolproof method of determining which ports needed to be updated in all cases, without introducing further changes in the ports infrastructure, then we could implement the method in the ports infrastructure, or in portmaster and portupgrade, and forget about the question that you have raised. >Should _all_ explicit and direct dependencies (to use your vocabulary) >be accounted for in the LIBDEPENDS of a port? The LIBDEPENDS are used to >bump PORTREVISIONs to trigger rebuilds. Not having all explicit and >direct dependencies listed there, reduces the use of PORTREVISION bumps >so much that their negative side effect (at least when they are not done >at the same moment as the original commit) becomes dominant (people >relying on libchk, bsdadminscripts, or the like are forced to rebuild >ports that are already consistent). > It is better in most cases to err on the side of caution and rebuild too much, than to rebuild too little, and have a broken system. But you seem to be conflating two different problems here, as I read it: the effectiveness of the PORTREVISION bumps is reduced when all direct dependencies aren't recorded in *_DEPENDS and a simplistic method like that in ports/Tools/scripts/bump_revision.pl is used to determine which ports need to be bumped. But in that case too little is being rebuilt, not too much. >Peter seems to be of my opinion by what he said above, marcus@ did >introduce USE_GETTEXT for many ports that already have indirect port >dependencies, so I assume that he agrees, too. On the other hand, pav@ >(who is among portmgr) seems to disagree (at least a year ago), as I >stated in my first mail: >http://lists.freebsd.org/pipermail/cvs-ports/2009-May/172173.html And he >is not the only one with that opinion. There are some strident portlint warnings that may cause some maintainers, rightly or wrongly, to add a direct dependency on devel/gettext, even when there is already an indirect dependency. So I wouldn't read too much into J. Marcus' actions. I suspect that Pav is weighing the costs of refactoring all of the *_DEPENDS in Ports to follow what you seem to be suggesting, and the added overhead of processing more dependencies during builds, versus the concern that a few users are going to have trouble during major upgrades if they are building from source on a running system (this doesn't seem to be a problem on tinderboxes and package-building clusters), and finding that it isn't worth the effort from his perspective. With the current practice, all dependencies may not be correctly recorded as direct dependencies, but at least (barring some other mistakes) they _are_ recorded. >Yes, the architecture of ports is insufficient for a good solution of >any kind, but as long as there is not even an agreement, what LIBDEPENDS >are supposed to contain, following port updates is harder than it should >be, because of the different strategies used to bump shared libraries >that affect many ports. > >Considering the few responses my posting got, either not many see the >need to reach an agreement or the posing was not clear or not concise >enough. (It is not the first time I tried to raise this issue.) Just because one thinks that, ideally, LIB_DEPENDS should contain all direct library dependencies, and that such a change may help resolve some problems, doesn't necessarily mean that one thinks that, in practice, all of them should be added -- because there is a cost to doing so. In principle, I agree with what I think that you are suggesting, that they should be added, but I can see why others may be hesitant to do this, and I haven't tried to estimate the added overhead on a system with a lot of ports. b.