Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Oct 2004 16:25:39 +0000
From:      Eivind Eklund <eivind@FreeBSD.org>
To:        Sebastian Schulze Struchtrup <seb@struchtrup.com>
Cc:        obrien@FreeBSD.org
Subject:   Re: alternative options for ports
Message-ID:  <20041014162539.GD1301@FreeBSD.org>
In-Reply-To: <416DAD91.8000002@struchtrup.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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_<portname>_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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041014162539.GD1301>