| 1 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> posted |
| 2 |
20080610150018.1cae5e34@××××××××××.com, excerpted below, on Tue, 10 Jun |
| 3 |
2008 15:00:18 +0100: |
| 4 |
|
| 5 |
> On Tue, 10 Jun 2008 09:49:04 -0400 |
| 6 |
> Richard Freeman <rich0@g.o> wrote: |
| 7 |
>> 4) Putting EAPI inside the ebuild, but in a manner that does not |
| 8 |
>> require sourcing using bash (ie comment at top of file). |
| 9 |
|
| 10 |
> - it doubles the number of file reads necessary during resolution. |
| 11 |
|
| 12 |
No comment, except that it should be cached after the first one, so the |
| 13 |
second read should be a memory read. |
| 14 |
|
| 15 |
> - it heavily restricts future syntax and meaning of EAPIs |
| 16 |
|
| 17 |
I don't see this. Putting it at a defined place in the ebuild and |
| 18 |
parsing it pre-source nails down the problem such that if a future format |
| 19 |
change is further incompatible, a primary EAPI can be defined that |
| 20 |
defines a further extension, a second line to look at in the ebuild, some |
| 21 |
external file, the filename, whatever, for the additional sub-eapi or |
| 22 |
whatever detail, much as extensions to various Internet RFCs have done |
| 23 |
when they've wanted to extend beyond what would fit in the then-current |
| 24 |
definitions. It does little to restrict the ultimate combined |
| 25 |
primary/secondary EAPI, where the primary simply defines where and how to |
| 26 |
look for the secondary. |
| 27 |
|
| 28 |
> - it makes comments have meaning |
| 29 |
|
| 30 |
Only if we choose the comment format, and then no more than shebang and |
| 31 |
similar solutions do. In the latter case it's an already recognized *ix |
| 32 |
solution. In the former, it's entirely possible to use a backward |
| 33 |
compatible EAPI= simple assignment that can be pre-parsed, and use the |
| 34 |
sub-eapi (minor part, in terms discussed elsewhere) if necessary to |
| 35 |
further define it using functions or the like. |
| 36 |
|
| 37 |
|
| 38 |
That said, I don't see the big deal to putting it in the file extension, |
| 39 |
when we're already breaking traditional content-defines-type rules by |
| 40 |
decreeing .ebuild extensions in the first place. I'd personally like to |
| 41 |
keep it a one-time fixed extension change, if only to force some |
| 42 |
discipline on the proliferation by forcing each new change to be |
| 43 |
reauthorized, meaning it's /really/ needed or it's simply not worth the |
| 44 |
trouble, but really, the precedent was already set when we accepted |
| 45 |
metadata in filename with the .ebuild thing in the first place, so |
| 46 |
there's little reason to fight it now, unless the proposal also |
| 47 |
eliminates that, and backward compatibility with it. |
| 48 |
|
| 49 |
-- |
| 50 |
Duncan - List replies preferred. No HTML msgs. |
| 51 |
"Every nonfree program has a lord, a master -- |
| 52 |
and if you use the program, he is your master." Richard Stallman |
| 53 |
|
| 54 |
-- |
| 55 |
gentoo-dev@l.g.o mailing list |
Archives