Gentoo Archives: gentoo-dev

From: Patrick Lauer <patrick@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Tue, 03 Nov 2009 22:05:07
Message-Id: 200911032304.58321.patrick@gentoo.org
In Reply to: Re: [gentoo-dev] FEATURES use or misuse? by Alexis Ballier
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

Subject Author
Re: [gentoo-dev] FEATURES use or misuse? Sebastian Pipping <sping@g.o>
Re: [gentoo-dev] FEATURES use or misuse? Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>