On Thu, 6 Sep 2012 01:11:45 -0700
Brian Harring <ferringb@gmail.com> wrote:

> A compatibility hack that stacks them is strongly advisable;
> something akin to the following:
> 
> Literally, we do the following:
> inherit() {
>   if eapi blah; then
>     local DEPEND PDEPEND RDEPEND
>     <usual saving/protection of DEPENDENCIES var>
>   else
>     <usual saving/protection of DEPEND/PDEPEND/RDEPEND vars>
>   fi
>   <normal sourcing machinery>
>   if eapi blah; then
>     local _deps=( ) _x
>     for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do
>       [ -n "${!_x}" ] && deps+=( "${!_x}" )
>     done
>     [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}"
>     unset DEPEND RDEPEND PDEPEND _x _deps
>     <normal stacking/restoration of DEPENDENCIES rules>
>   else
>     <normal stacking/restoration of RDEPEND/PDEPEND/DEPEND>
>   fi
> }
> 
> Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set 
> the DEPENDENCIES directly; those that have to support multiple eapi's 
> (aka, every fricking eclass that exists right now) can just use the 
> old form, shifting into the new form as things progress.

If we decide to go with a such a hack, then we either have to support
it indefinitely, or to decide to drop the support in some further EAPI.

If we go for the latter, then it's just delaying the ugly conditional
eclasses will have to suffer at some random point in the future. Well,
maybe two eclasses less if we wait with it for an EAPI which will
provide 'killer features' which will render the eclasses unusable with
older EAPIs. And way, it will be a bit confusing to remember two switch
points...

If we go for the former... then some developers will ask: why eclasses
and not ebuilds? Why?

-- 
Best regards,
Michał Górny