Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Oct 2010 17:26:05 -0700
From:      "David O'Brien" <obrien@freebsd.org>
To:        David DEMELIER <demelier.david@gmail.com>
Cc:        FreeBSD Ports <ports@freebsd.org>
Subject:   OPTIONS (was: editors/vim installs to /)
Message-ID:  <20101002002605.GA8018@dragon.NUXI.org>
In-Reply-To: <AANLkTi=vPKpaPL9L=pQN9EdWdEN3sf1pos6uGtJU7ybV@mail.gmail.com>
References:  <4C93AA31.5080202@DataIX.net> <AANLkTik%2B1rvY4ZYgzHRjaX8PBfD1UqNCNeadHqg3KBfo@mail.gmail.com> <20100918223933.GB85995@dragon.NUXI.org> <AANLkTi=vPKpaPL9L=pQN9EdWdEN3sf1pos6uGtJU7ybV@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote:
> What is "sufficiently clean" ? I wonder what is not clean in the
> options framework, so please tell me then we still can clean it?

When the Ports Collection was invented, ports maintainers were to
choose a reasonable set of configuration for the FreeBSD community
and have the port build that way.

Today we have ports that seem to expose every single option to GNU
configure and giving the user a puzzling choice of too many things.
Often the explanations are nothing more than restating the option
name and the user is left wondering what is X?  What does Y mean?
How do I know if I really want Z or not?  Why is threading so often
an OPTION and not just the default?  Why do I have to go read the
packages README and INSTALLING to figure out the caveats of say
enabling threading?  Or what the other list of things are and their
caveats?

1. One should not have to deal with the OPTIONS dialog just to 
'make extract' if one wants to check the license or otherwise
investigate a port before deciding to install it.

2. With the way OPTIONS handling is done, there isn't a way for me
to query if I built with the defaults or not.
Thus leading to every port I manually install looking like it was
customized just because /var/db/ports/${PORTNAME} exists.  Thus
implying I can no longer install the pre-build package.

3. OPTIONS are limited to only checkbox YES/NO settings.
Why can I not set PREFIX thru the OPTIONS framework and have it come
from /var/db/ports/${PORTNAME}/options on the 2nd and later builds?
Even the boolean NOPORTDOCS isn't available thru OPTIONS.
Thus it is an inconsistent way to configure a port.

4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in
/etc/make.conf, why does the OPTIONS dialog offer me
"[X] NLS Enable gettext support" instead of defaulting the
dialog to unchecked?

5. One cannot opt-out of OPTIONS.
WITHOUT_OPTIONS does not work to just get the defaults while skipping
the OPTIONS dialog.  Note, setting BATCH does a lot more than just
make OPTIONS non-interactive (for some ports it stops other
non-OPTIONS interaction with the user that one should see).  Thus
there is no way to get an uninterrupted default build of something.

6. One cannot opt-in/opt-out on a per-port basis.
WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS
should be supported to control the OPTIONS dialog just when
building ${PORTNAME}.

7. Setting ${PORTNAME}_WITH[OUT]_<SOME_OPTION> (or
WITH[OUT]_${PORTNAME}_<SOME_OPTION>) should set
WITH[OUT]_<SOME_OPTION> just when building ${PORTNAME}.
So that folks who don't want to be interrupted with OPTIONS every
time there is an update to the list can hardcode their choices in
/etc/make.conf.

8. OPTIONS make a mess in the typescript file from
'script typescript make', and the choices are totally unreadable vs.
'script typescript make -DWITH_FOO -WITHOUT_BAR'.

-- 
-- David  (obrien@FreeBSD.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"



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