1 |
On Fri, Mar 09, 2012 at 09:47:50AM -0800, Zac Medico wrote: |
2 |
> On 03/09/2012 09:31 AM, Michael Orlitzky wrote: |
3 |
> > On 03/09/12 12:11, Ulrich Mueller wrote: |
4 |
> >>>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote: |
5 |
> >> |
6 |
> >>>> What if bash starts to parse the script completely and barfs at |
7 |
> >>>> 'syntax error' before it starts executing stuff? |
8 |
> >> |
9 |
> >>> It doesn't parse the script completely, it executes line-by-line, so |
10 |
> >>> we can bail out early. |
11 |
> >> |
12 |
> >> How can you tell that this behaviour won't be changed in a future bash |
13 |
> >> version? |
14 |
> >> |
15 |
> > |
16 |
> > Who's to say that in the future my computer won't be made out of |
17 |
> > delicious ice cream, eliminating the need for EAPIs entirely? |
18 |
> > |
19 |
> > Chances are, this would break thousands of scripts, so we hope they |
20 |
> > wouldn't do it. If it does happen, we either deal with it then, or don't |
21 |
> > upgrade to that version of bash -- the same as we would do with any |
22 |
> > other massive breaking change. |
23 |
> |
24 |
> Ulrich is talking about extensions which require a newer version of |
25 |
> bash. These kinds of extensions are quite common and don't cause |
26 |
> "massive breaking" because people simply have to upgrade bash in order |
27 |
> to use the new extensions, and their old scripts continue to run because |
28 |
> the new extensions don't interfere with backward compatibility. |
29 |
> |
30 |
> Your eapi() function proposal is especially fragile in this context |
31 |
> because it assumes that the installed version of bash will be able to |
32 |
> execute a script that may target a newer version of bash. This is a |
33 |
> special case that is typically not a problem, although it is a major |
34 |
> problem under the specific conditions that your eapi() function approach |
35 |
> induces. |
36 |
|
37 |
Pragmatic reality, the eapi function actually would work fine. As |
38 |
pointed out elsewhere, bash parses as it goes- which isn't going to |
39 |
change. |
40 |
|
41 |
If someone invokes 'eapi happy-meal' and it's not supported, |
42 |
the sourcing is stopped immediately, cache gets -happy-meal for the |
43 |
EAPI, and the pm continues to ignore the ebuild till either the |
44 |
ebuilds mtime changes (which case it redoes the metadata regen) or the |
45 |
PM now supports that EAPI, and... you guessed it, redoes the metadata |
46 |
regen. The cache behaviour is basically the same regardless of the |
47 |
EAPI mechanism. |
48 |
|
49 |
Now, this isn't to say everyone views the function as *optimal*. |
50 |
People can argue about that as much as they'd like. |
51 |
|
52 |
The point however is that it *would* work. Anyone claiming |
53 |
fragility/otherwise needs to put forth actual code examples. |
54 |
|
55 |
|
56 |
> Anyway, lets focus on our main goal, which is to decide on a way to |
57 |
> obtain the EAPI _without_ sourcing the ebuild. |
58 |
|
59 |
Nitpicking, but the point needs be made; this is *your* requirement. |
60 |
The requirement is to be able to deploy new globals/bash |
61 |
requirements/whatever. |
62 |
|
63 |
There is a difference. |
64 |
|
65 |
~brian |