1 |
On Tuesday 03 November 2009 22:26:24 Alexis Ballier wrote: |
2 |
> > To quote: |
3 |
> > "FEATURES is a portage specific package manager configuration |
4 |
> > variable not specified in PMS and cannot reliably be used in ebuilds |
5 |
> > or eclasses." |
6 |
> |
7 |
> For distcc & ccache, let me quote ebuild.sh code: |
8 |
> |
9 |
> if hasq distcc $FEATURES ; then |
10 |
> export PATH="/usr/lib/distcc/bin:$PATH" |
11 |
> [[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}" |
12 |
> fi |
13 |
> |
14 |
> if hasq ccache $FEATURES ; then |
15 |
> export PATH="/usr/lib/ccache/bin:$PATH" |
16 |
> [...] |
17 |
> |
18 |
> Do you want an example how to mimic this with portage without having |
19 |
> neither distcc nor ccache in FEATURES? |
20 |
> Even with portage, checking the FEATURES variable isn't reliable. If |
21 |
> you do not want to fix the real bugs and check/disable distcc/ccache |
22 |
> for any reason, then check PATH. |
23 |
Well, if a user wants to shoot himself hard enough in the foot he (or she, or |
24 |
it) can do that. But in the general case we should allow silly assumptions, |
25 |
one of them being that if a user sets FEATURES="distcc" that he wants to use |
26 |
distcc and will use the portage mechanisms to enable it. The assumption that |
27 |
the FEATURE variable actually controls the behaviour of such features seems |
28 |
like a good idea to me, almost as good as digital watches. |
29 |
|
30 |
> If you want to keep this simple, write an eclass providing functions |
31 |
> for disabling/checking these features. |
32 |
Wow, that's a nice way to make things complex :) |
33 |
(and why not let the package manager manage such things?) |
34 |
|
35 |
> > Well then, I suggest we finally start documenting reality and fix |
36 |
> > PMS. The use of the FEATURES variable, while it has been there |
37 |
> > for ... uhm ... as long as I can think back, actually :), should not |
38 |
> > be randomly suppressed. |
39 |
> |
40 |
> If you want to fix PMS, then send a patch |
41 |
I tried, and as I've been saying for a long time they get rejected. |
42 |
Funnily not by any dev but by some random user, but who cares :) |
43 |
With the current attitude PMS will be marginalized and worked around by |
44 |
people. Reality is what you perceive. |
45 |
|
46 |
> rephrasing it to explain why |
47 |
> it isn't correct to check FEATURES in some cases. On the other hand, as |
48 |
> its name implies, PMS is a spec, not a documentation on why every |
49 |
> single choice has been made. |
50 |
It's not a spec. Any engineer who has been involved in the spec creation or |
51 |
update process will gladly show you where it fails (for example not |
52 |
documenting, on purpose, some bits instead of documenting them with the note |
53 |
that this is nonstandard behaviour. A real specification will document such |
54 |
errata because then anyone working with it knows the potential issues ...) |
55 |
|
56 |
|
57 |
> > ( /me points at bash 3.0 ) |
58 |
> |
59 |
> Ever thought about backward compatibility and keeping a sane upgrade |
60 |
> path? Because that's exactly what this EAPI & PMS debate is all about |
61 |
> IMHO. |
62 |
Well, I don't want to be rude to you. But please, try using the KDE eclass |
63 |
with bash 3.0. Or maybe, just for fun (yeah, I know) portage. |
64 |
|
65 |
Please do it and then tell me how forcing bash 3.2, then documenting the need |
66 |
for bash 3.0, is in any way sane or consistent. |
67 |
|
68 |
We broke backwards compatibility about a year ago. Since then we've collected |
69 |
so many bash-3.0-incompatible bits that a migration back is technically |
70 |
possible, but practically no longer an acceptable solution (And trying to |
71 |
force it will make you lots of new "friends"). Your objections come a year to |
72 |
late. Now we have to accept reality and decide how to live with it. |
73 |
|
74 |
Calling EAPI is ... well ... I can't even think of a place to start to explain |
75 |
how wrong it is. How on earth are you going to parse an eclass that supports |
76 |
multiple EAPIs where one EAPI were to support features of bash 4? |
77 |
The only way to do it would be to force bash 4 on all lower EAPIs, or make |
78 |
per-EAPI eclasses, or forbid use of new bash features in eclasses. |
79 |
All horrible ways to avoid fixing the problem. All workaroundable by just |
80 |
accepting things as they are. |
81 |
|
82 |
Sometimes EAPI is not a viable solution to a problem. |
83 |
|
84 |
Take care, |
85 |
|
86 |
Patrick |