| 1 |
Hi! |
| 2 |
|
| 3 |
On Sat, 16 May 2009, Ciaran McCreesh wrote: |
| 4 |
> On Sat, 16 May 2009 11:27:10 +0200 |
| 5 |
> Tobias Klausmann <klausman@g.o> wrote: |
| 6 |
> > Change the spec, then. |
| 7 |
> |
| 8 |
> If we change the spec, we can't do anything with the change until we're |
| 9 |
> absolutely sure that everyone's updated both their ebuilds and their |
| 10 |
> package manager for it. |
| 11 |
|
| 12 |
The change the extension *once*, and make an EAPI spec at the top |
| 13 |
of the file for that file format. |
| 14 |
|
| 15 |
I'd rather have the extension change once, with pain, than with |
| 16 |
every EAPI change. My opinion is that reflecting the EAPI in the |
| 17 |
file name is a very, very Bad Idea. |
| 18 |
|
| 19 |
> > Actually, I personally would prefer taking it out of the |
| 20 |
> > parsed-by-bash part entirely. Add it as a shebang-like line at |
| 21 |
> > the top: |
| 22 |
> > |
| 23 |
> > #EAPI-1 |
| 24 |
> > |
| 25 |
> > as the first or second line. Allowing it on the second line |
| 26 |
> > allows you to later bolt on a true shebang-line if you should so |
| 27 |
> > desire. Only having to look at the first two lines makes finding |
| 28 |
> > it out easier (note that I don't call that parsing on purpose). |
| 29 |
> |
| 30 |
> Would mean we'd have to change every existing ebuild everywhere. |
| 31 |
|
| 32 |
No, it means we have to change every ebuild of which we claim |
| 33 |
that it works that way. Versioned file structures *without* |
| 34 |
changing the extension have been done and they have worked. |
| 35 |
|
| 36 |
Yes, there may be pain along the way. But that is true no matter |
| 37 |
which route we go. |
| 38 |
|
| 39 |
What people prefer is in no small way tied to the amount of pain |
| 40 |
they expect from a given solution. And they're right to do so. |
| 41 |
|
| 42 |
Regards, |
| 43 |
Tobias |
| 44 |
-- |
| 45 |
Found on a small utility knife in MIT's lab supply: |
| 46 |
"Caution. Blade is sharp. Keep out of children." |
Archives