| 1 |
On Wed, 25 Feb 2009 04:49:51 -0800 |
| 2 |
Brian Harring <ferringb@×××××.com> wrote: |
| 3 |
> 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as |
| 4 |
> the first statement (simplest way). |
| 5 |
|
| 6 |
Doesn't solve anything over having it as a variable, and has a messy |
| 7 |
upgrade path. |
| 8 |
|
| 9 |
> - global scope changes can occur (inherit mechanism changes |
| 10 |
> included). |
| 11 |
|
| 12 |
Global scope changes can no more occur than they can with it as a |
| 13 |
variable. All it does is changes where the barfing occurs to slightly |
| 14 |
earlier on. |
| 15 |
|
| 16 |
> - transition is slightly icky; basically one of the following is |
| 17 |
> required- |
| 18 |
> a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason |
| 19 |
> for this is that current managers obviously lack an eapi |
| 20 |
> function, to make managers available *now* blow up the || die is |
| 21 |
> required. This solution can be deployed now, no transition required |
| 22 |
> although at some point stating "eapi is required retroactively for |
| 23 |
> all eapis" would be wise to eliminate the need for the || die (cut |
| 24 |
> support basically for old managers) |
| 25 |
|
| 26 |
Global scope die is very very messy. This leaks out to users in the |
| 27 |
form of horrible messages that make the user think something's badly |
| 28 |
broken. |
| 29 |
|
| 30 |
> b) bashrc trickery, defines an eapi if it's unset. Said eapi |
| 31 |
> function exports EAPI=$1, optionally triggering a die if the eapi |
| 32 |
> isn't 0,1,2 (since any later eapi would require a manager upgrade |
| 33 |
> which would also have the eapi function). |
| 34 |
|
| 35 |
Unportable, and still leaks out to users. |
| 36 |
|
| 37 |
This whole thing only looks neat until you think about it... |
| 38 |
|
| 39 |
-- |
| 40 |
Ciaran McCreesh |
Archives