1 |
Jeremy Olexa wrote: |
2 |
|
3 |
> This causes me pain on my hosts that don't have >=bash-3.1[0] for |
4 |
> /bin/bash. Because I can't install portage with an old bash until I |
5 |
> get a new python installed which uses python.eclass which isn't |
6 |
> supported with my /bin/bash (quite circular indeed) |
7 |
> |
8 |
> Technically there are workarounds for me...but it is still annoying. |
9 |
> So...what do we do? A) Specifically allow >=bash-3.1 features in |
10 |
> ebuilds/eclasses. or B) revert the commit because the PMS says[1] that |
11 |
> we comply with >bash-3.0 |
12 |
> |
13 |
> Please discuss, thanks. |
14 |
|
15 |
I'd vote for updating the spec; it's going to be a pita trying to maintain |
16 |
the tree without +=. From our discussion, you said it was fine for prefix |
17 |
to specify a minimum version of bash for bootstrap, but clearly that can't |
18 |
be 3.1 when the draft PMS says 3.0. |
19 |
|
20 |
I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 |
21 |
lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 |
22 |
requires at least that version (only unstable on mips as against 2.1.1-r2) |
23 |
It might be worth skipping to 3.2, since that would simplify regex handling. |
24 |
|
25 |
Not sure how that should be framed, or when it's okay to do it; clearly a |
26 |
spec has to be updatable, whether it's by a specified policy, or |
27 |
explicitly. |