From owner-freebsd-ports@FreeBSD.ORG Thu Oct 14 16:25:51 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 007A616A4CE; Thu, 14 Oct 2004 16:25:51 +0000 (GMT) Received: from srv01.sparkit.no (srv01.sparkit.no [193.69.116.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A5E943D3F; Thu, 14 Oct 2004 16:25:50 +0000 (GMT) (envelope-from eivind@FreeBSD.org) Received: from ws.nada ([193.69.114.88]) by srv01.sparkit.no (8.12.11/8.12.11) with ESMTP id i9EGPjtd078962; Thu, 14 Oct 2004 18:25:45 +0200 (CEST) (envelope-from eivind@FreeBSD.org) Received: from ws.nada (localhost [127.0.0.1]) by ws.nada (8.12.9/8.12.10) with ESMTP id i9EGPetH012699; Thu, 14 Oct 2004 16:25:40 GMT (envelope-from eivind@ws.nada) Received: (from eivind@localhost) by ws.nada (8.12.9/8.12.10/Submit) id i9EGPebC012698; Thu, 14 Oct 2004 16:25:40 GMT (envelope-from eivind) Date: Thu, 14 Oct 2004 16:25:39 +0000 From: Eivind Eklund To: Sebastian Schulze Struchtrup Message-ID: <20041014162539.GD1301@FreeBSD.org> References: <416C0DE8.3000004@struchtrup.com> <416C35A5.4040703@vonostingroup.com> <20041013123840.GB1301@FreeBSD.org> <20041013193547.GB53895@hub.freebsd.org> <416DAB2A.3060900@vonostingroup.com> <416DAD91.8000002@struchtrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416DAD91.8000002@struchtrup.com> User-Agent: Mutt/1.5.4i cc: "Frank J. Laszlo" cc: freebsd-ports@FreeBSD.org cc: obrien@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: Thu, 14 Oct 2004 16:25:51 -0000 On Thu, Oct 14, 2004 at 12:34:57AM +0200, Sebastian Schulze Struchtrup wrote: > > >>>On Tue, Oct 12, 2004 at 03:51:01PM -0400, Frank Laszlo wrote: > >>>If you've got more *specific* problems with usability (like the batch > >>>build problem above), I'm very interested, as I'm trying to collect > >>>these for doing a new round of fixes for the options support in > >>>bsd.port.mk. > >>> > >> > >> > >>BTW, has anyone started to impliment the NO__OPTIONS feature > >>that was requested? > >> > >> > >That sounds like a great idea to me, I would definately like to devote > >some time to implementing such a feature if the demand is there. It > >doesnt sound like it would be very difficult to acomplish. And I'm > >glad to see someone shares my feelings on dialog's in ports :) > > > I think there will be some major changes with these config options. A > global NO_OPTIONS is also planned like David has written. > I understand your problems, too. I have also had this one (or some more) > times, starting a large portupgrade over night and to see the next > morning that it has stopped at 9pm inside a dialog. > But I think this is solved by a global NO_OPTIONS setting for those who > don't like it. We should get a little more fine grained - NO_MENUCONFIG is the primary issue (as far as I can tell), while NO_OPTIONS suggest to me that we block all *reading* of options. I personally would like (and probably use) a NO_MENUCONFIG for some kinds of builds, but I'd still want it to respect my stored options. In the NO_MENUCONFIG case, we should probably also register user options, ie if a user type WITH_FLEXRSP=yes on the command line, it should be registered in the /var/db/ports/ configuration file. > Probably it would be best to wait a few days and check what else needs > to be changed. Here are relevant extracts from a discussion I had with O'Brien on the theme: On Thu, Jul 15, 2004 at 04:22:37PM -0700, David O'Brien wrote: > On Thu, Jul 15, 2004 at 10:50:36AM +0000, Eivind Eklund wrote: > > Every unnecessary email sent is a drain on this. Every negative e-mail > > sent is a large drain on this. Every time somebody implement something > > (a personal example is the OPTIONS stuff for ports) and somebody > > afterwards comment "I don't like it" (and especially if they refuse to > > answer WHY they don't like it) is a HUGE drain on motivation and > > available resources for FreeBSD. > > Are you speaking about my emails WRT "OPTIONS" over the past weekend? Those were OK - they didn't make me happy, of course, but you have concrete issues, and concrete issues we have to deal with. What has made me unhappy and demotivated WRT OPTIONS is a couple of others that has repeated "I don't like it" or similar, and when I've tried to first ask and then press them on "What is it you dislike? Tell me, and I'll try to find some way to fix it", they have refused to answer. This demotivated me enough that I didn't have the energy to try to do much more with the stuff right after the original commit. As for the issues you brought up (I'd been planning to contact you about them anyway), the ones I've noted are: - Issues with release build - fixed by setting BATCH - Too many option popups - I think we could possible make this a little better by batching all the option stuff including what is necessary for dependencies up front, so users can start a port, and when they see it going forward, they know it will not block. - Too many "small options" listed. I believe we really should list all options; if it is not important enough to ask the users about, it isn't important enough to have an option for at all. Very very special case users can compile from source or modify the port. I've been trying to think of some way to prioritize options etc, but nothing feels at all right. I've been able to come up with one potential improvement for dependecy controlling options: Having a global setting that specifies "Minimal", "All", "Installed", or "Standard", which would make all ports being installed auto-select what depenency set they have when the set is optional (ie, configurable by WITHOUT_X11, WITH_MAD_LIB, etc). "Minimal" would minimize dependencies, "All" would maximize dependencies, "Installed" would be minimal + wahtever was already available, and "Standard" would be the recommended set from the porter. - Multiple requests for root password when building as a user: This I consider a bug, and will try to find some way to fix. - Generating packages with options. This is presently done with slave ports, which to me seems a stopgap solution, but one that mostly solve our problems for the time being. Over time, I'd like to have some way to automatically generate packages with some variations, ideally by listing some options sets in the port, have the package building build all of them, then find the differences between the installed sets and merge those to a single package with all variants of the divergent files included. This would require that port builds for those ports were reproducable, though. If you've got more concrete issues, I'd love to hear about them, as I'd really like this stuff to be good. I still feel that it was a good thing to get this into the tree because it actually force people to think about options, but it seems it is still some distance to go. I thought I'd covered everything by covering all objections and comments that had been raised when this was originally brought up on the mailing lists; alas, that turned out to be wrong. And reply from O'Brien: > I have not dug deep enough to find out if this already exists -- but it > would be nice to have it so that if "NO_${PORTNAME}_OPTIONS" is defined, > it would "comment out" any OPTIONS statements in the ${PORTNAME} port. > I have a long list of knobs in /etc/make.conf for particular packages > and I prefer this method over the interactive nature of OPTIONS for > many, but not all, ports. Eivind.