From owner-freebsd-ports@FreeBSD.ORG Fri May 20 21:00:45 2005 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5207816A4CE; Fri, 20 May 2005 21:00:45 +0000 (GMT) Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A03343D31; Fri, 20 May 2005 21:00:44 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP <20050520210041.ZYBR10612.lakermmtao12.cox.net@dolphin.local.net>; Fri, 20 May 2005 17:00:42 -0400 Received: from dolphin.local.net (localhost.local.net [IPv6:::1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j4KL0FvS005144; Fri, 20 May 2005 16:00:15 -0500 (CDT) (envelope-from conrads@cox.net) Date: Fri, 20 May 2005 16:00:10 -0500 From: "Conrad J. Sabatier" To: Ade Lovett Message-ID: <20050520160010.1c9c3ebe@dolphin.local.net> In-Reply-To: <24E0B4F7-C17F-4038-A4D4-3936FE3BF4E0@freebsd.org> References: <20050518234933.05e2584b@dolphin.local.net> <20050519183922.GB6978@xor.obsecurity.org> <20050520074620.GB95023@pcwin002.win.tue.nl> <24E0B4F7-C17F-4038-A4D4-3936FE3BF4E0@freebsd.org> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-ports@freebsd.org Subject: Re: Disabling dependency on esound in ports builds X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 21:00:45 -0000 On Fri, 20 May 2005 01:00:59 -0700, Ade Lovett wrote: > > On May 20, 2005, at 00:46 , Stijn Hoop wrote: > > I do know the reason why this kind of code was added: it was > > considered incorrect behaviour that port A would NOT automatically > > pick up support for library B if it was installed by the user. > > That's more an artefact of configure scripts especially being coded > to simply check for the mere existence of a library in order to use > it, instead of the more correct approach of explicitly requesting -- > enable-foo (or equivalent). > > Bringing in all the necessary hacks to only activate extra code if > the user (or port Makefile) has explicitly requested it is (at best) > an awkward task. It's considerably easier to give up and go with the > > exists() constructs which, as I've mentioned, do (in most cases) at > least register the dependency. > > > [...] and considering reproducible package building > > This right here hits the nail right on the head. exists() > constructs, acting as the bandaids they are around poorly written > configuration scripts, can, and do, cause problems for building and > distributing packages in anything but an absolute virgin environment. Well, in the case of GNOME and its constituent packages, it seems that we have a case of automatic (indirect) dependencies run amok. For instance, just because a particular package may depend on, say, gtk2, does that mean it should also automatically depend on a dozen or more other components of GNOME as well, the majority of which will not be employed in any way by the package? I think not! I just now did a "pkg_info -R esound-0.2.35_2", and was astonished to see the number of packages listing esound as a dependency, even when it's quite apparent that esound provides absolutely no additional functionality to many of those packages. I know we had quite a heated discussion some time ago in one of the lists (or perhaps in comp.unix.bsd.freebsd.misc) on the subject of the evils of indirect dependencies, but I don't recall any fruitful outcome from it. I really don't know what to suggest, or where such a discussion might lead if we were to pursue it again, but it certainly does seem that there's ample opportunity for some major cleaning up in the area of port dependencies. The current approach just seems rather heavy-handed, if you ask me. There should be some facility for a more fine-tuned approach, leaning more in the direction of "when in doubt, leave it out", rather than the current "throw it in just to be sure" methodology. -- Conrad J. Sabatier -- "In Unix veritas"