1 |
> To quote: |
2 |
> "FEATURES is a portage specific package manager configuration |
3 |
> variable not specified in PMS and cannot reliably be used in ebuilds |
4 |
> or eclasses." |
5 |
|
6 |
For distcc & ccache, let me quote ebuild.sh code: |
7 |
|
8 |
if hasq distcc $FEATURES ; then |
9 |
export PATH="/usr/lib/distcc/bin:$PATH" |
10 |
[[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}" |
11 |
fi |
12 |
|
13 |
if hasq ccache $FEATURES ; then |
14 |
export PATH="/usr/lib/ccache/bin:$PATH" |
15 |
[...] |
16 |
|
17 |
Do you want an example how to mimic this with portage without having |
18 |
neither distcc nor ccache in FEATURES? |
19 |
Even with portage, checking the FEATURES variable isn't reliable. If |
20 |
you do not want to fix the real bugs and check/disable distcc/ccache |
21 |
for any reason, then check PATH. |
22 |
|
23 |
If you want to keep this simple, write an eclass providing functions |
24 |
for disabling/checking these features. |
25 |
|
26 |
> Well then, I suggest we finally start documenting reality and fix |
27 |
> PMS. The use of the FEATURES variable, while it has been there |
28 |
> for ... uhm ... as long as I can think back, actually :), should not |
29 |
> be randomly suppressed. |
30 |
|
31 |
If you want to fix PMS, then send a patch rephrasing it to explain why |
32 |
it isn't correct to check FEATURES in some cases. On the other hand, as |
33 |
its name implies, PMS is a spec, not a documentation on why every |
34 |
single choice has been made. |
35 |
|
36 |
> So ... what's your opinion? Should we do things as they are correct, |
37 |
> or as they are specified in PMS? |
38 |
|
39 |
PMS may have some flaws, but not these, sorry. |
40 |
|
41 |
> ( /me points at bash 3.0 ) |
42 |
|
43 |
Ever thought about backward compatibility and keeping a sane upgrade |
44 |
path? Because that's exactly what this EAPI & PMS debate is all about |
45 |
IMHO. |
46 |
|
47 |
|
48 |
Regards, |
49 |
|
50 |
Alexis. |