Date: Sat, 16 Oct 2004 01:19:28 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Eivind Eklund <eivind@FreeBSD.org> Cc: freebsd-ports@FreeBSD.org Subject: Re: alternative options for ports Message-ID: <20041016081928.GA80039@dragon.nuxi.com> In-Reply-To: <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> <20041014162539.GD1301@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 14, 2004 at 04:25:39PM +0000, Eivind Eklund wrote: > On Thu, Oct 14, 2004 at 12:34:57AM +0200, Sebastian Schulze Struchtrup wrote: > > 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. That is quite reasonable, and does address the essence of the issue. > 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. I'm not so sure about that... I could be doing a one-off build or playing with (testing) something. I think it should be a deliberate action by the user that records a setting in /var/db/ports. I wonder if we should just leave those type of knob settings for the command-line or /etc/make.conf. > - 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. Why are slave ports a bad solution? One example problem with options, since they are compile time only and don't work for 'pkg_add' users is all our printing related ports. We could easily replace a2ps-{letter,a4}; psutils-{letter,a4}; mp-{letter,a4}; enscript-{letter,a4}, lprps-{letter,a4}; etc... with a single port with "OPTIONS= letter "" on a4 "" off" now that we have 'OPTIONS'. I wonder how many of our users would be happy that we were back to catering to just 1/2 the paper-size regions. I think our slave ports is a fine solution issues like this. -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041016081928.GA80039>