| 1 |
2009/5/17 Ryan Hill <dirtyepic@g.o>: |
| 2 |
> On Sun, 17 May 2009 17:56:06 +0200 |
| 3 |
> Piotr Jaroszyński <peper@g.o> wrote: |
| 4 |
> |
| 5 |
>> Hello, |
| 6 |
>> |
| 7 |
>> I have just updated GLEP 55 [1], hopefully making it a bit clearer. |
| 8 |
>> |
| 9 |
>> Just FYI, my order of preference of solutions is: |
| 10 |
>> |
| 11 |
>> 1. EAPI-suffixed ebuilds (obviously) |
| 12 |
>> 2. EAPI in the filename with one-time extension change |
| 13 |
>> 3. Easily fetchable EAPI inside the ebuild and one-time extension change |
| 14 |
>> |
| 15 |
>> I can live with any of these if that's what it takes to move forward. |
| 16 |
> |
| 17 |
> I'd like 2 if we could have multiple same-versioned ebuilds of different |
| 18 |
> EAPI. 3 is good enough for me. |
| 19 |
|
| 20 |
That's covered in the GLEP: |
| 21 |
|
| 22 |
"Note that it is still not permitted to have more than one ebuild with |
| 23 |
equal category, package name, and version. Although it would have the |
| 24 |
advantage of allowing authors to provide backwards compatible ebuilds, |
| 25 |
it would introduce problems too. The first is the requirement to have |
| 26 |
strict EAPI ordering, the second is ensuring that all the ebuilds for |
| 27 |
a single category/package-version are equivalent, i.e. installing any |
| 28 |
of them has exactly the same effect on a given system." |
| 29 |
|
| 30 |
I don't see a way to overcome these problems in a sensible way. |
| 31 |
|
| 32 |
-- |
| 33 |
Best Regards, |
| 34 |
Piotr Jaroszyński |
Archives