Date: Sun, 3 Oct 2010 10:22:46 +0200 From: David DEMELIER <demelier.david@gmail.com> To: obrien@freebsd.org Cc: FreeBSD Ports <ports@freebsd.org> Subject: Re: OPTIONS (was: editors/vim installs to /) Message-ID: <AANLkTinkasFFQ8ssbTSdbYUS%2BJ-tYMc1U3w9rkUCk9Gd@mail.gmail.com> In-Reply-To: <20101002002605.GA8018@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <AANLkTik%2B1rvY4ZYgzHRjaX8PBfD1UqNCNeadHqg3KBfo@mail.gmail.com> <20100918223933.GB85995@dragon.NUXI.org> <AANLkTi=vPKpaPL9L=pQN9EdWdEN3sf1pos6uGtJU7ybV@mail.gmail.com> <20101002002605.GA8018@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/10/2 David O'Brien <obrien@freebsd.org>:
> 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? =C2=A0What does Y mean?
> How do I know if I really want Z or not? =C2=A0Why is threading so often
> an OPTION and not just the default? =C2=A0Why do I have to go read the
> packages README and INSTALLING to figure out the caveats of say
> enabling threading? =C2=A0Or 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. =C2=A0Thus
> implying I can no longer install the pre-build package.
>
make rmconfig ?
> 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.
>
I agree. As I said in 4, OPTIONS should follow the defined knob in
make.conf. But for not boolean knobs there is something we can also
do, spawn a little textbox to define an option with a string. Example
:
[X] WITH_X foo bar
[ ] WITH_Y foo bar baz
[fr_FR en_GB] LANGS to be build
Here pressing enter on LANGS would spawn a little textbox that can be
fulfilled by the user. The little problem is how to tell to OPTIONS
that it's not a boolean entry.
> 4. When I build misc/mc-light and have "WITHOUT_NLS=3Dyes" in
> /etc/make.conf, why does the OPTIONS dialog offer me
> "[X] NLS Enable gettext support" instead of defaulting the
> dialog to unchecked?
>
I agree with this inconsistency, I think with a little of work OPTIONS
framework should be to follow KNOB to enable an option if it's already
defined by the user. This would be great for people that use
WITHOUT_GNOME, WITHOUT_X11 and so on. I think it's possible to do it.
pkgsrc do it with PKG_DEFAULT_OPTIONS=3D setting.
> 5. One cannot opt-out of OPTIONS.
> WITHOUT_OPTIONS does not work to just get the defaults while skipping
> the OPTIONS dialog. =C2=A0Note, 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). =C2=A0Thus
> 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.
>
Yes, check my answer at 4.
> 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'.
>
There is a disadvantages with knobs here, you must define knob each
time you install/upgrade a port. Of course you can do it with the
make.conf or the portconf system.
OPTIONS also prints -DSOMETHING when compiling.
Definitely, I like knobs and I like options. But mixing the both is
painful. You should check by typing make config or sometime lsknobs or
even reading the makefile.
The best thing to do is switch totally to a way to configure a port
and remove the other one. I think we should try to upgrade the options
framework with what I said at 4. and 3. It's possible but we need some
work.
Kind regards,
--=20
Demelier David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinkasFFQ8ssbTSdbYUS%2BJ-tYMc1U3w9rkUCk9Gd>