From owner-freebsd-ports@FreeBSD.ORG Sun Aug 17 16:47:19 2003 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 36B8B37B401 for ; Sun, 17 Aug 2003 16:47:19 -0700 (PDT) Received: from mail.dt.e-technik.uni-dortmund.de (mail.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3958E43FAF for ; Sun, 17 Aug 2003 16:47:18 -0700 (PDT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from m2a2.dyndns.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1])0933D8BFD for ; Mon, 18 Aug 2003 01:47:17 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 90FE62F6B; Mon, 18 Aug 2003 01:47:14 +0200 (CEST) To: Matthias Andree In-Reply-To: <20030817180804.GA14907@unsane.de> (Oliver Braun's message of "Sun, 17 Aug 2003 20:08:04 +0200") References: <20030817180804.GA14907@unsane.de> From: Matthias Andree Date: Mon, 18 Aug 2003 01:47:14 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-ports@freebsd.org Subject: Re: Port WITH_* options and updates/portupgrade 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: Sun, 17 Aug 2003 23:47:19 -0000 Oliver Braun writes: > Take a look at the MAKE_ARGS hash in $PREFIX/etc/pkgtools.conf. > > You can use things like > > MAKE_ARGS['mail/postfix']='BATCH=yes POSTFIX_OPTIONS=\"SASL2\"' > > there. Michael Edenfield writes: > Anything that you can pass on the make command line you can put into > /usr/local/etc/pkgtools.conf. This is what I have for postfix to > always build with DB3: > > MAKE_ARGS = { > 'mail/postfix' => 'BATCH=1 POSTFIX_OPTIONS=DB3', > } [...] > The downside is that you need to remember to always use the pkgtools > like portupgrade. It's also easy to forget to add new ports when you > need them, but eventually it becomes second nature. And that's exactly the problem: the "solution" is local to the tool, rather than global for the ports system. I have no implementation ideas yet, but let's assume the system is called "portsconfig". The functionality I'd like to see is: a. in batch mode, portsconfig will retrieve the "last time" settings and, lacking these, resort to the port's defaults; regardless of the way the port is built (manually vs. via portupgrade). b. in interactive (non-batch mode), portsconfig will take care of the dialogue. c. The port just passes in tuples (description, option) and its own name and portsconfig takes care of presenting the dialog or retrieving the data. d. data is persistent until deleted (so each option will also have an option to counter it, so that the system remembers WITHOUT_TDB so I can get rid of an earlier WITH_TDB.) /var/db/pkgoptions? e. information is recorded in packages built so that portupgrade on a port that was installed by pkg_add -r gets the same options, without the user editing pkgtools.conf or looking up anything. (+OPTIONS file?) I wonder if there's much to it implementation-wise. Essentially, ports would have to standardize how they query, store, retrieve their A4=yes, SASL2, WITH_TDB, options, and if it saves some work, port maintainers will go for it. The user will also profit from a more consistent ports configuration. Listing the port configuration variables in another variable, or automatically extracting them if they have a standardized name format, might work. make -V will be one of our friends. -- Matthias Andree