From owner-freebsd-ports@FreeBSD.ORG Sat Mar 12 23:57:18 2011 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 DD122106566C for ; Sat, 12 Mar 2011 23:57:18 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id C0A1D8FC14 for ; Sat, 12 Mar 2011 23:57:18 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta04.emeryville.ca.mail.comcast.net with comcast id JPwS1g0011afHeLA4PxJLC; Sat, 12 Mar 2011 23:57:18 +0000 Received: from comcast.net ([98.203.142.76]) by omta17.emeryville.ca.mail.comcast.net with comcast id JPx91g0111f6R9u8dPxAQu; Sat, 12 Mar 2011 23:57:16 +0000 Received: by comcast.net (sSMTP sendmail emulation); Sat, 12 Mar 2011 15:57:09 -0800 Date: Sat, 12 Mar 2011 15:57:09 -0800 From: Charlie Kester To: freebsd-ports@freebsd.org Message-ID: <20110312235709.GG79028@comcast.net> Mail-Followup-To: freebsd-ports@freebsd.org References: <4D76426A.2010006@secnap.com> <20110312215307.GB26099@lonesome.com> <20110312221233.GD79028@comcast.net> <4D7C00D5.8070003@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4D7C00D5.8070003@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Mailer: Mutt 1.4.2.3i X-Composer: Vim 7.3 Subject: Re: Superfluous dependencies X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 23:57:18 -0000 On Sat 12 Mar 2011 at 15:25:09 PST Doug Barton wrote: >On 03/12/2011 14:12, Charlie Kester wrote: >>I'm not aware of any tool that will display a similar dependency tree >>for a port *before* it is installed. > >portmaster doesn't _quite_ do that, but it does walk you through all of >the config screens (and thus, the related dependencies) prior to >building, then present you a list of everything that will be built >before you build it. Yep. That's marginally better than "make all-depends-list" because it filters out any dependencies that would have been pulled in by disabled options. > >That said, what is really needed is for the OPTIONS framework to take >environmental preferences into account when dealing with defaults. In >other words, if WITHOUT_X11 is defined in make.conf, then the defaults >for OPTIONS that are related to requiring X11 stuff should be off. There >are a few ports that have rolled their own manipulation of this, but >that logic really needs to be in bsd.options.mk. Any volunteers? > X11 is just one example. There are similar scenarios involving XML crap (excuse my language). What's really needed are better tools to help maintainers see what their ports are installing, and for them to exercise more disciple in asking "Is this really necessary, or should I make it optional? Is it really a run dependency, or is it only needed for the build?" (*) And maybe also to give end users better tools too, so they can be better informed about the consequences of installing a particular port or enabling certain options. Threads like this one usually get started when someone has an unpleasant surprise. The WITHOUT_X11 logic wrt options can get complicated, btw. If you're installing a GTK or KDE app, for example, you probably don't want WITHOUT_X11 disabling any of its options! Or do we want to interpret WITHOUT_X11 as a signal that the user intends to run a textmode system only, and disallow installation of any GUI ports whatsoever? (* For me, testing the port in a tinderbox with --clean-packages has always had a sobering effect. When it takes all day -- or more! -- to finish the test, I start looking for things to trim. Some of you might recall me asking a while ago whether I could put some pre-built manpages under files, in order to avoid pulling in a bunch of docbook dependencies.)