From owner-freebsd-ports@FreeBSD.ORG Fri Oct 15 14:15:55 2004 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 208E016A4CE for ; Fri, 15 Oct 2004 14:15:55 +0000 (GMT) Received: from av6-2-sn2.hy.skanova.net (av6-2-sn2.hy.skanova.net [81.228.8.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id D260943D58 for ; Fri, 15 Oct 2004 14:15:53 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av6-2-sn2.hy.skanova.net (Postfix, from userid 502) id A27DD37E48; Fri, 15 Oct 2004 16:15:52 +0200 (CEST) Received: from smtp2-1-sn2.hy.skanova.net (smtp2-1-sn2.hy.skanova.net [81.228.8.177]) by av6-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8E37A37E42 for ; Fri, 15 Oct 2004 16:15:52 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp2-1-sn2.hy.skanova.net (Postfix) with SMTP id 29B1737E46 for ; Fri, 15 Oct 2004 16:15:51 +0200 (CEST) Received: (qmail 80422 invoked by uid 1001); 15 Oct 2004 14:15:51 -0000 Date: Fri, 15 Oct 2004 16:15:51 +0200 From: Erik Trulsson To: Gary Jennejohn Message-ID: <20041015141551.GA80394@falcon.midgard.homeip.net> Mail-Followup-To: Gary Jennejohn , Michael Nottebrock , freebsd-ports@freebsd.org References: <200410151419.44415.michaelnottebrock@gmx.net> <200410151404.i9FE4Jrc006244@peedub.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410151404.i9FE4Jrc006244@peedub.jennejohn.org> User-Agent: Mutt/1.5.6i cc: freebsd-ports@freebsd.org Subject: Re: alternative options for ports 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, 15 Oct 2004 14:15:55 -0000 On Fri, Oct 15, 2004 at 04:04:19PM +0200, Gary Jennejohn wrote: > > Michael Nottebrock writes: > > This is exactly why we need more fine-grained (slave-)-ports that translate > > features into binary packages which can be added and removed easily. If a > > user asks "How can I get this or that feature in $package" and the answer is > > "you need install the ports-collection, set some option and then recompile > > the port" it means that the port is flawed and a slave-port which translates > > the feature into a binary package is needed. > > > > > You're joking, right? I certainly am not prepared or willing to make a > slave port for every twinkie option in the ports which I maintain! Not > to mention the explosion in the number of files in the ports tree. Especially when you consider ports like multimedia/mplayer which has over 20 different options that are independent of each other. If you want a slave-port for each (valid) combination of options, you would need over 2^20 different slave ports. Adding a million extra slave-ports just to make sure that nobody ever needs to recompile a port instead of using a binary package is just not realistic. Personally I tend to think there are too many slave-ports already which just take up a lot of space in the ports-tree and make updating the ports-tree go slower, but then I almost never use binary packages but build everything from source. (I.e. I would probably barely notice if all binary packages suddenly disappeared never to return.) -- Erik Trulsson ertr1013@student.uu.se