On 2021-08-16 18:06, Joonas Niilola wrote:
What's the rush with 8 anyway? We still have eclasses that don't even support 7. And since 6 is now, sigh, deprecated, any bump to ebuilds depending on those eclasses will add to the evergrowing CI issue list right? I'd say it's more important to secure EAPI-7 support there first.
...or we could just skip supporting EAPI 7 support in such packages and go from 6 straight to 8. In my own experience with EAPI bumping, I would rank migration difficulty (with the more difficult cases listed first) as follows:
1. 5 to 6 - a lot of changes to take into account, all of them adding up to a massive pain in the neck - especially if patches have to be regenerated in order to work with eapply;
2. 6 to 7 - the trailing-slash-in-D-and-ED thing can be a nuisance but that's pretty much it, even moving packages from DEPEND to BDEPEND can be considered minor owing to how little breakage not doing it can cause (cross-building packages IS useful, that's how we initially bootstrapped dev-lang/go on riscv for instance, but it's not that widespread);
3. 7 to 8 - everything except the bash version bump can be handled quickly with grep and mgorny's checklist.
In short, so far I've found the cost of adding EAPI 8 support minimal comparing to support for earlier versions.
-- Marecki
OpenPGP_signature
Description: OpenPGP digital signature
