1 |
On Wednesday 04 November 2009 01:33:23 Sebastian Pipping wrote: |
2 |
> Patrick Lauer wrote: |
3 |
> > Calling EAPI is ... well ... I can't even think of a place to start to |
4 |
> > explain how wrong it is. How on earth are you going to parse an eclass |
5 |
> > that supports multiple EAPIs where one EAPI were to support features of |
6 |
> > bash 4? The only way to do it would be to force bash 4 on all lower |
7 |
> > EAPIs, or make per-EAPI eclasses, or forbid use of new bash features in |
8 |
> > eclasses. All horrible ways to avoid fixing the problem. |
9 |
> |
10 |
> I find restricting the eclass to Bash 3 is a natural, maintainable |
11 |
> approach to this. How would "fixing he problem" work from your |
12 |
> perspective? |
13 |
It doesn't :) |
14 |
You can't use the "new" features in the "old" eclass, even with conditionals |
15 |
separating the execution paths. Which means you'd have to either not use them |
16 |
(which makes me wonder why we allow features when they can't be used). |
17 |
Or you clone the eclass and now maintain the code in two places (wheee, bad |
18 |
engineering!) |
19 |
|
20 |
So we end up with a bad solution either way. There are some clean options, but |
21 |
they tend to be a bit more complex. For example globally forcing minimum |
22 |
versions (which makes upgrade paths a bit more interesting). |
23 |
|
24 |
> |
25 |
> > All workaroundable by just |
26 |
> > accepting things as they are. |
27 |
> |
28 |
> What do you mean by "accepting things as they are"? |
29 |
|
30 |
People have been doing things (in this case using bash 3.2 features) for a |
31 |
long time (about a year now). Even when some people warned about the impact |
32 |
noone cared. |
33 |
|
34 |
So more and more these "illegal" features get used, and as there are no |
35 |
sanctions for it (not even from QA!) they are accepted as allowed. |
36 |
|
37 |
Fast forward and you have an informal standard (using += in ebuilds is ok) |
38 |
that is agreed on by everyone. Yes, everyone, because when people pointed out |
39 |
that it was a Bad Thing there was no reaction, no opposition, nothing. |
40 |
|
41 |
So the Gentoo developer community agreed on it. The only thing not reflecting |
42 |
that agreement is PMS. So we fix it. |
43 |
|
44 |
Same with FEATURES variable. Been used for the last few years. Works. |
45 |
Most reliable way to do a few things if you assume that users don't actively |
46 |
try to break things. And instead of properly documenting it we pretend it |
47 |
never happened? |
48 |
|
49 |
|
50 |
> You have been talking of "accepting reality" repeatedly and I'm left |
51 |
> wondering what you actually mean by that. I especially fail to see who |
52 |
> is trying to conceal(?) reality and reality about what. |
53 |
Ok, |
54 |
|
55 |
from stable portage ebuilds: |
56 |
RDEPEND=" [snip] |
57 |
>=app-shells/bash-3.2_p17 |
58 |
|
59 |
from KDE eclass: |
60 |
RESTRICT+=" test" |
61 |
|
62 |
gentoo-x86/app-shells/bash $ ls -1 *.ebuild |
63 |
bash-3.1_p17.ebuild |
64 |
bash-3.2_p39.ebuild |
65 |
bash-3.2_p48-r1.ebuild |
66 |
bash-3.2_p48.ebuild |
67 |
bash-4.0_p28.ebuild |
68 |
bash-4.0_p33.ebuild |
69 |
bash-4.0_p35.ebuild |
70 |
|
71 |
So we can either dance around all day and pretend bash 3.0 still has any |
72 |
relevance, or we stop the nonsense and tolerate reality as it is. |
73 |
|
74 |
We can also pretend FEATURES never served a purpose and doesn't fix any |
75 |
issues, then spend lots of time workarounding around working solutions because |
76 |
we just declared them illegal. |
77 |
|
78 |
I don't know how much time you have and what your priorities are, but I'm not |
79 |
going to care about such a waste of time, and it goes very low on my list of |
80 |
priorities. If there's a decision on this I doubt most devs will care much, so |
81 |
anyone wanting to have the FEATURES use removed will end up having to do it |
82 |
himself, against the resistance of package maintainers (don't touch my package |
83 |
etc. etc.) |
84 |
|
85 |
Have fun, |
86 |
|
87 |
Patrick |