| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 31-12-2010 10:02, Ulrich Mueller wrote: |
| 5 |
> Hi, |
| 6 |
> |
| 7 |
> after approval of EAPI 4, there are now 5 different EAPIs available, |
| 8 |
> and it's hard to remember what features are offered by which EAPI. |
| 9 |
> |
| 10 |
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new |
| 11 |
> ebuilds. As a first step, a warning could be added to repoman that |
| 12 |
> would be triggered whenever a new ebuild with an EAPI less than 2 is |
| 13 |
> committed. |
| 14 |
|
| 15 |
I agree that having too many EAPI versions around can only lead to |
| 16 |
confusion. Furthermore, it can require extra work from developers to |
| 17 |
ensure compatibility for ebuilds and more importantly eclasses. |
| 18 |
Instead of deprecating EAPIs 0 and 1, I'd suggest we deprecate EAPIs 1 |
| 19 |
and 2, though. As others have recalled, we'll have to maintain EAPI 0 |
| 20 |
around indefinitely, and EAPI 3 includes all the features in EAPIs 1 and |
| 21 |
2. This way we can leave the system set packages alone. |
| 22 |
|
| 23 |
> At a later time, the warning could be changed to an error. When most |
| 24 |
> of the tree has been updated to EAPI 2 or newer, we could also think |
| 25 |
> about actively converting the remaining ebuilds. (Currently this |
| 26 |
> doesn't look feasible though, as about half of the tree is still at |
| 27 |
> EAPI=0. [1]) |
| 28 |
|
| 29 |
Sounds a good idea (for EAPIs 1 and 2). |
| 30 |
|
| 31 |
> Opinions? |
| 32 |
> |
| 33 |
> Ulrich |
| 34 |
> |
| 35 |
> [1] <http://blogs.gentoo.org/alexxy/2010/11/06/some-interesting-stats-about-gentoo-portage-tree/> |
| 36 |
> |
| 37 |
|
| 38 |
One way we could drop EAPI 0 would be if we do a major review of tree |
| 39 |
and repo formats to improve upgrade paths, which would however likely |
| 40 |
require breaking backwards compatibility at such point. |
| 41 |
I believe such a change would only be acceptable, if we would pack |
| 42 |
enough features and safety measures that it would ensure another break |
| 43 |
would not need to be done for a long time. |
| 44 |
|
| 45 |
- -- |
| 46 |
Regards, |
| 47 |
|
| 48 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
| 49 |
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng |
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v2.0.16 (GNU/Linux) |
| 52 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 53 |
|
| 54 |
iQIcBAEBAgAGBQJNIJeVAAoJEC8ZTXQF1qEPnpIQAM73/W5vvIz9DJjHKiSPp8OX |
| 55 |
Z4ezg0lBiT5ZpeN4caY5jdhh0lRWE8raEDBKiCjJhm/lnkdqs3hpYx5ogHJxhGrM |
| 56 |
2HkzF1wfDFt5/l0PnqhCyGlS6o/v/zN4w0d3TQKsl1hq5bz5fge2SCe37bZXSC/h |
| 57 |
Did6ijW17wsu+OQOP4ihI7CibLy0G9khi+zDQBoKsC8UVwfzO013aRuVORySP+d+ |
| 58 |
fgyR4wMOgduVqlsIKqLBVMTRzPWCUDvmyGd2eVJ8zhl5i/n1Hnq8Pw3QTwSmK15s |
| 59 |
wfUUQH7N7uuWgC8w2i2JEy717yzjB5CRZX54MIFgIk2zFxPZe6mBsMeafL9oPNeR |
| 60 |
3J2qJvlULM7BOxjkdXakE+089TM3R3d32ul9qcBmnlWbpbxHwzH/h7dAoCRb1kwW |
| 61 |
DVG9MS1FGRar7EnKLVKhDh554cG47vS15b6q0fOSbxKNyjKa28XJVR7GQNtjk85Z |
| 62 |
ACJdG5J9yCidgWWyiCcdF6uDAKGOl6FqJDngGLVrXsSWyL6nuUA68hEAMfuC5Y3D |
| 63 |
EIWsexsRqVT2tksZ8a/LlhpCH74ksbibrH5sLw/0P0qrhQvK3K0whfIXF+kjSVy9 |
| 64 |
qnixHkSYTWUDkYB8cWrBemroD6bLQvm8pzOurOrSKeLY8ax28H2Dqkz914W6H4Ae |
| 65 |
3DYA5ct0nnFQV4FOvUzA |
| 66 |
=nBkm |
| 67 |
-----END PGP SIGNATURE----- |
Archives