Re: [gentoo-dev] FEATURES use or misuse?

[Patrick Lauer]

On Tuesday 03 November 2009 22:26:24 Alexis Ballier wrote:
> > To quote:
> > "FEATURES is a portage specific package manager configuration
> > variable not specified in PMS and cannot reliably be used in ebuilds
> > or eclasses."
>
> For distcc & ccache, let me quote ebuild.sh code:
>
> if hasq distcc $FEATURES ; then
> 	export PATH="/usr/lib/distcc/bin:$PATH"
>         [[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}"
> fi
>
> if hasq ccache $FEATURES ; then
> 	export PATH="/usr/lib/ccache/bin:$PATH"
> [...]
>
> Do you want an example how to mimic this with portage without having
> neither distcc nor ccache in FEATURES?
> Even with portage, checking the FEATURES variable isn't reliable. If
> you do not want to fix the real bugs and check/disable distcc/ccache
> for any reason, then check PATH.
Well, if a user wants to shoot himself hard enough in the foot he (or she, or 
it) can do that. But in the general case we should allow silly assumptions, 
one of them being that if a user sets FEATURES="distcc" that he wants to use 
distcc and will use the portage mechanisms to enable it. The assumption that 
the FEATURE variable actually controls the behaviour of such features seems 
like a good idea to me, almost as good as digital watches.

> If you want to keep this simple, write an eclass providing functions
> for disabling/checking these features.
Wow, that's a nice way to make things complex :)
(and why not let the package manager manage such things?)
 
> > Well then, I suggest we finally start documenting reality and fix
> > PMS. The use of the FEATURES variable, while it has been there
> > for ... uhm ... as long as I can think back, actually :), should not
> > be randomly suppressed.
>
> If you want to fix PMS, then send a patch
I tried, and as I've been saying for a long time they get rejected.
Funnily not by any dev but by some random user, but who cares :)
With the current attitude PMS will be marginalized and worked around by 
people. Reality is what you perceive.

> rephrasing it to explain why
> it isn't correct to check FEATURES in some cases. On the other hand, as
> its name implies, PMS is a spec, not a documentation on why every
> single choice has been made.
It's not a spec. Any engineer who has been involved in the spec creation or 
update process will gladly show you where it fails (for example not 
documenting, on purpose, some bits instead of documenting them with the note 
that this is nonstandard behaviour. A real specification will document such 
errata because then anyone working with it knows the potential issues ...)

 
> > ( /me points at bash 3.0 )
>
> Ever thought about backward compatibility and keeping a sane upgrade
> path? Because that's exactly what this EAPI & PMS debate is all about
> IMHO.
Well, I don't want to be rude to you. But please, try using the KDE eclass 
with bash 3.0. Or maybe, just for fun (yeah, I know) portage.

Please do it and then tell me how forcing bash 3.2, then documenting the need 
for bash 3.0, is in any way sane or consistent.

We broke backwards compatibility about a year ago. Since then we've collected 
so many bash-3.0-incompatible bits that a migration back is technically 
possible, but practically no longer an acceptable solution (And trying to 
force it will make you lots of new "friends"). Your objections come a year to 
late. Now we have to accept reality and decide how to live with it.

Calling EAPI is ... well ... I can't even think of a place to start to explain 
how wrong it is. How on earth are you going to parse an eclass that supports 
multiple EAPIs where one EAPI were to support features of bash 4? 
The only way to do it would be to force bash 4 on all lower EAPIs, or make 
per-EAPI eclasses, or forbid use of new bash features in eclasses.
All horrible ways to avoid fixing the problem. All workaroundable by just 
accepting things as they are.

Sometimes EAPI is not a viable solution to a problem.

Take care,

Patrick