| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 09/28/2013 10:12 PM, heroxbd@g.o wrote: |
| 5 |
> "Rick \"Zero_Chaos\" Farina" <zerochaos@g.o> writes: |
| 6 |
> |
| 7 |
>> On 09/28/2013 03:00 AM, Ulrich Mueller wrote: |
| 8 |
>>>>>>>> On Sat, 28 Sep 2013, heroxbd wrote: |
| 9 |
>>> |
| 10 |
>>>> I am revisiting this topic based on previous discussions[1,2,3]. |
| 11 |
>>> |
| 12 |
>>>> There seems to be a constant need for toolchain with a new EAPI. The |
| 13 |
>>>> only block is "how can we upgrade from an ancient system?", "don't |
| 14 |
>>>> bump or the upgrade path will be break". Let's figure out a solid |
| 15 |
>>>> upgrade path consciously, with a test farm of ancient systems, and |
| 16 |
>>>> then bump the EAPI of toolchain. |
| 17 |
>>> |
| 18 |
>>> The upgrade path is not at all what is blocking this. In its 20130409 |
| 19 |
>>> meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no |
| 20 |
>>> longer required for the upgrade path of users' systems." |
| 21 |
>>> |
| 22 |
>>> The reason why toolchain packages are still at EAPI 0 was explained in |
| 23 |
>>> this posting: |
| 24 |
>>> http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 |
| 25 |
>>> |
| 26 |
>>> AFAICS, changing that is entirely the task of the toolchain team. |
| 27 |
> |
| 28 |
> Thank you for the clarification, Ulrich. |
| 29 |
> |
| 30 |
>> Yes, it is entirely the task of the toolchain team, and looks like |
| 31 |
>> heroxbd joined the toolchain team and would like to push the rest of his |
| 32 |
>> team for this update. Something I greatly thank him for. |
| 33 |
>> |
| 34 |
>> I don't think any dev wants to (or really could) force toolchain to |
| 35 |
>> update individually, however, if motivated people want to join the team |
| 36 |
>> and help, his question appeared to be will it be permitted to be |
| 37 |
>> updated. |
| 38 |
> |
| 39 |
> Can't agree with you more. |
| 40 |
> |
| 41 |
> It's just a starting point, though. I still don't have a clear plan yet. |
| 42 |
> |
| 43 |
> After reading carefully the thread Ulrich pointed out, it seems that |
| 44 |
> refactoring ebuild/eclass is invevitable, which calls for an overlay to |
| 45 |
> carry it on. |
| 46 |
> |
| 47 |
While I'm not nearly good enough to detail how this should happen |
| 48 |
exactly, please, may I beg, do an eclass revision for this. The fact |
| 49 |
that this hasn't been done clearly implies it is a lot of work. Let's |
| 50 |
not risk stable, let's simply make toolchain-r1.eclass or whatever, and |
| 51 |
bump that to eapi5. At the end of the day, this allows working and |
| 52 |
testing without odd issues, and if everyone really hates that idea you |
| 53 |
can simply drop the changes into the original eclass when it's all done. |
| 54 |
|
| 55 |
Thanks, |
| 56 |
Zero |
| 57 |
-----BEGIN PGP SIGNATURE----- |
| 58 |
Version: GnuPG v2.0.20 (GNU/Linux) |
| 59 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 60 |
|
| 61 |
iQIcBAEBAgAGBQJSR5V3AAoJEKXdFCfdEflKDcMP/0B01NSlVaTEM6oDIF324YNP |
| 62 |
p1G1vNVh86avVCL+0sLfmDPID547qWZOfemoids94xemrvyVYnJFccvtg7KBH+ck |
| 63 |
k4h/LJ2pTEvCGiL3KyUngYc6XN3YMwOHJsRD+jr0cmYG+GG0Lm5UUb73PPhgLtOv |
| 64 |
Ltrm4B68w3x1qqucrd3/PgBF7tfjoBdvB8XqkJ+u9RoMFfFb2BUH3n6VZ2Ngkzup |
| 65 |
BU5PaakC8tBGhZvkLrd81RHTY7iHuM5HGh4ZK0GSfVsq+pYIwFpWztKGcSQmEpxe |
| 66 |
oLgMZD2g5GAykkUhzcrvc6p091wsOylenAgnhZZL2cy2pZE99TLTUw6y/Q7+HUiN |
| 67 |
mKdXG/JbXQ/FmkhqVivvWM43g3bumEvYub5EegUa6MGrHjCqRjsO+GQq68CGTbMq |
| 68 |
TYpZXUGtCdAdMIyvk6wMhTWlrO2TQmakkj/tqHif1TsyVIIYZlTKLosftqxVbpxd |
| 69 |
54Mr1oI+LM7oHGghy5/7BJz0V0U7BWIXiDBBf4HJ1k4gybkRBqCx7I+YSYib9ZZg |
| 70 |
jvHwJv9kiksduO5dQk/NmKgWgmyBTaYzZYPvxJyXp2uzk3Nmgf7JAwN2AHuUrFXZ |
| 71 |
5LLwPC36bwEyAdKABHwIZsVdquBm2smFLIFy4oMoxcmEHBaOmOKBSrIKN0iLPYnD |
| 72 |
ZfpgorrlwCLdiqV+VeKU |
| 73 |
=jY8E |
| 74 |
-----END PGP SIGNATURE----- |
Archives