| 1 |
On Saturday 16 May 2009 13:14:23 Duncan wrote: |
| 2 |
> I mean, for the longest time, the main (among many) boosting claim seemed |
| 3 |
> to be that the speed difference between in-file and in-filename made the |
| 4 |
> former prohibitive in practice. |
| 5 |
|
| 6 |
No, performance was never the point of GLEP 55. People like to talk about it |
| 7 |
because, as we all know, Gentoo is for ricers, but it's not relevant and |
| 8 |
never has been, except to the extent that we don't want to make performance |
| 9 |
worse than it is now. |
| 10 |
|
| 11 |
> The argument was originally made that a simple highly specified EAPI= |
| 12 |
> declaration in the file itself was too restrictive of all the ways it |
| 13 |
> could be specified now -- until it began to be pointed out every time the |
| 14 |
> argument was made that the filename method was very similarly |
| 15 |
> restricted. |
| 16 |
|
| 17 |
No, no-one has ever claimed that the restricted EAPI= method is bad because |
| 18 |
they /want/ to be able to set it using weird bash tricks. The problem is |
| 19 |
that, if it appears as a bash assignment you /can/ set it using weird bash |
| 20 |
tricks, and making the PM's own parsing accept a subset of what can happen |
| 21 |
when the ebuild /is/ eventually sourced is going to make a mess. |
| 22 |
|
| 23 |
> I'd argue no, it's no more unintuitive than any other format definition |
| 24 |
> choice. It's the basic format definition, using the long accepted method |
| 25 |
> of "magic values" at a "magic location" to define the format version. |
| 26 |
> That's very basic definitional, restricted only to the degree necessary |
| 27 |
> for practical application of the definition. Therefore, it's not |
| 28 |
> unintuitive, or at least, certainly no more so than arbitrarily defining |
| 29 |
> it to be in the filename instead, because "intuitive" now gets defined by |
| 30 |
> the format definition at an extremely basic level, well below the level |
| 31 |
> at which all the "intuitive or not" fancy stuff gets addressed. |
| 32 |
|
| 33 |
"The format definition at an extremely basic level" is bash, which has no such |
| 34 |
restrictions. |
| 35 |
|
| 36 |
For comparson, another alternative that some people have suggested is putting |
| 37 |
it in a specially formatted comment. This avoids the issue I mentioned |
| 38 |
because bash doesn't try to parse those at all, so the only rules are those |
| 39 |
that specify what format the comment should be in. On the other hand, this |
| 40 |
isn't backwards compatible with current package managers. |
Archives