1 |
On Mon, Mar 12, 2012 at 11:59 AM, Ciaran McCreesh |
2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
3 |
> On Tue, 13 Mar 2012 04:57:04 +1300 |
4 |
> Kent Fredric <kentfredric@×××××.com> wrote: |
5 |
>> I think this notion should be concluded before we continue debating as |
6 |
>> to how best to implement EAPI declarations. |
7 |
>> |
8 |
>> Is it really so fixed that ".ebuild" will only ever be bash ? |
9 |
> |
10 |
> What version of bash are we talking about here? It's not the case that |
11 |
> ebuilds will always be bash 3, which is enough to make GLEP 55 the safe |
12 |
> option. |
13 |
|
14 |
Well, we do always have the option of keeping the EAPI= syntax but |
15 |
making it more strict per the proposals, and then grepping it out |
16 |
rather than sourcing the ebuild. That seems likely to always work |
17 |
with bash. Then if we ever switched to some other format we'd have to |
18 |
reconsider whether we want to tweak this approach further or adopt |
19 |
GLEP 55. |
20 |
|
21 |
If you envision a future where big changes are inevitable over the |
22 |
long term, then just going with GLEP 55 is probably the cleanest |
23 |
solution. If you envision a future where we are likely to never move |
24 |
away from bash, or if we do it is so far off that we're content to let |
25 |
our children deal with it, then other approaches may seem nicer. |
26 |
|
27 |
I guess the question is whether we need to future-proof against a |
28 |
future that may never come. Then again, as we're seeing from systemd |
29 |
a lot of stuff that "always" was done in bash doesn't necessarily have |
30 |
to stay that way. |
31 |
|
32 |
Rich |