On Sun, Sep 2, 2012 at 6:52 AM, Vaeth <va...@mathematik.uni-wuerzburg.de> wrote: > So in any case, for the _user_ an EAPI bump is (with the current EAPIs) > always a benefit. This should be worth to establish the policy currently.
Your example only cited cases where an EAPI bump to 5 has a benefit. If that is the case, I'm fine with making an effort to migrate as many ebuilds as possible to EAPI 5. However, what is the benefit to users from migrating to EAPI 1, or 2, etc? The policy you're recommending would have required expending effort to implement every one of those for every ebuild in the tree without those kinds of end-user benefits. What will the benefit be for migrating to EAPI 6, or 7, or fred (EAPIs are not numbers, and they aren't ordered either)? And since EAPIs aren't actually ordered, is the latest one whichever is actually last approved, or the one which is "most functional?" Suppose EAPI xml defines an ebuild format in xml that isn't parsed by bash, whose purpose is mainly to allow simple ebuilds to be simplified further but which is really only appropriate for 20% of the ebuilds in the tree? It isn't good to assume that newer EAPIs include all the features of the earlier ones - they just are different specifications for behavior. Maybe somebody will come up with a reason to have an EAPI that only works with packages that use cmake for building, or whatever. The bottom line is that it may be desirable in the future to have different branches of EAPIs followed by different packages. So, if we want to make a policy that we should use EAPI5 whenever possible I'm fine with that, if the benefits to users are worth the costs. However, why extend this to every EAPI that follows when the benefits of those are not yet known? Let's look at a different situation - --as-needed. It was realized that supporting this across the tree has significant benefits for users, so we made a push to make it happen. Packages that didn't support this had bugs filed, and they were fixed, and today it is the default. However, what we DIDN'T do is just make a policy that all packages have to support all possible options in LDFLAGS, but rather we just focused on the one we actually cared about. You don't even need a "policy" to enact these kinds of changes. There was never a policy that all ebuilds must support --as-needed, and there may be legitimate reasons for individual packages to not support it today. However, when the case was made that this benefits end-users then everybody just jumped on board, since, well, most of us are nice guys who do that sort of thing. :) Rich
