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