Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Sun, Sep 2, 2012 at 6:52 AM, Vaeth <vaeth@××××××××××××××××××××××××.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