1 |
On Wed, 11 Nov 2015 12:52:05 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> >>>>> On Wed, 11 Nov 2015, Michał Górny wrote: |
5 |
> |
6 |
> > I'm not convinced we ought to do this for EAPI < 6. It is a breaking |
7 |
> > change after all, and as such changes the behavior of EAPI < 6 |
8 |
> > ebuilds. |
9 |
> |
10 |
> Which according to PMS should assume bash version 3.2. Also, AFAICS |
11 |
> the only feature where the compat settings could have any impact is |
12 |
> this setting from compat42: |
13 |
> |
14 |
> If set, bash does not process the replacement string in the pattern |
15 |
> substitution word expansion using quote removal. |
16 |
> |
17 |
> All other compat changes affect either only POSIX mode, or interactive |
18 |
> mode, or string comparison (where the compat32 setting disables locale |
19 |
> specific behaviour and uses strcmp instead, so effectively the compat |
20 |
> setting should be saner). |
21 |
|
22 |
Ok, I recalled the issue I was particularly concerned about. |
23 |
|
24 |
PV="1_beta2" |
25 |
MY_PV="${PV/_/~}" |
26 |
|
27 |
This triggers different behavior between bash<=4.2 and bash>=4.3, with |
28 |
the latter requiring: |
29 |
|
30 |
PV="1_beta2" |
31 |
MY_PV="${PV/_/\~}" |
32 |
|
33 |
(which in turns breaks older). Now, if someone put a conditional on |
34 |
BASH_VERSINFO that worked around this discrepancy, introducing |
35 |
BASH_COMPAT suddenly breaks it by forcing the old behavior when |
36 |
BASH_VERSINFO indicates the new behavior is expected. |
37 |
|
38 |
Not saying this is very likely to happen. However, we are clearly |
39 |
violating the idea behind PMS by allowing it to happen retroactively. |
40 |
|
41 |
However, enabling BASH_COMPAT in EAPI 6 is a good thing. For example, |
42 |
because people in EAPI 6 no longer need to be concerned about this |
43 |
discrepancy. |
44 |
|
45 |
-- |
46 |
Best regards, |
47 |
Michał Górny |
48 |
<http://dev.gentoo.org/~mgorny/> |