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>