alternative options for ports
David O'Brien
obrien at FreeBSD.org
Sat Oct 16 01:19:29 PDT 2004
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 at FreeBSD.org)
More information about the freebsd-ports
mailing list