Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Patrick Lauer <patrick@g.o>
Subject: Re: FEATURES use or misuse?
Date: Tue, 3 Nov 2009 23:04:58 +0100
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


Replies:
Re: FEATURES use or misuse?
-- Sebastian Pipping
Re: FEATURES use or misuse?
-- Ciaran McCreesh
References:
FEATURES use or misuse?
-- Patrick Lauer
Re: FEATURES use or misuse?
-- Alexis Ballier
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: FEATURES use or misuse?
Next by thread:
Re: FEATURES use or misuse?
Previous by date:
Re: FEATURES use or misuse?
Next by date:
Re: FEATURES use or misuse?


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.