From owner-freebsd-ports@FreeBSD.ORG Fri May 20 07:06:12 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 8D70716A4CE for ; Fri, 20 May 2005 07:06:12 +0000 (GMT) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF0043DAC for ; Fri, 20 May 2005 07:06:12 +0000 (GMT) (envelope-from ade@FreeBSD.org) Received: from hellfire.lovett.com ([67.134.38.149]) by mail.lovett.com with esmtpa (Exim 4.51 (FreeBSD)) id 1DZ1a0-000MqC-Ae; Fri, 20 May 2005 00:05:56 -0700 In-Reply-To: <20050519183922.GB6978@xor.obsecurity.org> References: <20050518234933.05e2584b@dolphin.local.net> <20050519183922.GB6978@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v730) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ade Lovett Date: Fri, 20 May 2005 00:06:05 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.730) 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 07:06:12 -0000 On May 19, 2005, at 11:39 , Kris Kennaway wrote: > On Wed, May 18, 2005 at 11:49:33PM -0500, Conrad J. Sabatier wrote: > >> Is there any standardized technique (using portupgrade's >> /usr/local/etc/pkgtools.conf) for disabling the inclusion of >> esound for >> ports which depend on it? I find esound to be a troublesome package >> which often results in the slowing down or chopping up of audio >> playback >> when the system is under moderate to heavy load. >> > > WITHOUT_ESOUND=yes In this particular case, that knob does indeed work most of the time. Explaining to software authors in general to not provide configure (or other) scripts that bring in extra functionality based on previously installed software, without providing for a specific flag that should be turned on (thus allowing a proper dependency to be registered by *any* package management system).. well, that's left as an exercise to the interested reader. This is one of the reasons that I would consider code along the lines of: .if exists(somelibrary) || defined(WITH_something) foo_DEPENDS+= ... .endif to be fundamentally flawed and in violation of POLA, where, if port A has such an (exists) dependency on port B, the following sequence: install A install B portupgrade A results in the second (A) being subtly different from the first, in that it is using extra functionality from B, without explicitly asking the user whether that's OK. The fact that the dependencies are actually correctly registered is something of a mitigating factor, but is certainly not an excuse for such "dependency-creep". -aDe