| 1 |
Ciaran McCreesh wrote: |
| 2 |
> On Mon, 24 Dec 2007 10:52:53 +0000 |
| 3 |
> Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 4 |
>> Ciaran McCreesh wrote: |
| 5 |
>> > On Mon, 24 Dec 2007 06:03:12 +0000 |
| 6 |
>> > Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 7 |
>> >> * Set the EAPI inside the ebuild in a way that makes it easy to |
| 8 |
>> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is |
| 9 |
>> >> no backward compatibility issue. |
| 10 |
>> > |
| 11 |
>> > It's both a backwards and a forwards compatibility issue. |
| 12 |
>> > |
| 13 |
>> Yeah, so forwards into the future where it's impossible to maintain |
| 14 |
>> this format (er..) there'll be another type of ebuild for your |
| 15 |
>> purported long-term solution. |
| 16 |
> |
| 17 |
> Hopefully that'll be EAPI 2, and hopefully we're talking months rather |
| 18 |
> than years. |
| 19 |
> |
| 20 |
Whatever. EAPI="2" works fine with current software. Could you tell me why |
| 21 |
you're so hot on export'ing EAPI? I thought it was only relevant, |
| 22 |
environment-wise, to the ebuild and subshells. What is the use case for |
| 23 |
exporting it externally? |
| 24 |
|
| 25 |
> * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor |
| 26 |
> across EAPIs removing features, nor EAPIs changing eclasses. |
| 27 |
> |
| 28 |
I don't see what's wrong with EAPI (if set, otherwise implicitly whatever |
| 29 |
the ebuild sets, or 0 if not set there) only applying to the file it's |
| 30 |
declared in. |
| 31 |
|
| 32 |
Since we can't remove eclasses, it would be useful to continue allowing them |
| 33 |
to examine the EAPI variable for future compatibility. I'm sure there are |
| 34 |
other restrictions imposed by this "enhancement" which make maintenance |
| 35 |
more difficult for no benefit to the maintainer. |
| 36 |
|
| 37 |
|
| 38 |
-- |
| 39 |
gentoo-dev@g.o mailing list |
Archives