On Tue, Sep 11, 2012 at 7:13 AM, Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 6 Sep 2012 01:11:45 -0700
> Brian Harring <ferri...@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.
It's a transitional hack; we support it as long as we need the
transition coverage. Meaning if by EAPI7, everyone is using EAPI5 and
up (or by EAPI7 it's basicaly insane to try and support
0,1,2,3,4,5,6,7), we drop the transition code in EAPI8. This is no
different to how RDEPEND/DEPEND autosetting was phased out.
> 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.
Hate to say "na uh", but... na uh. The point is as long as an eclass
has to support older EAPI's, they can use set DEPEND/RDEPEND and it
would work fine.
If the eclass needs the newer depends types (hdep, fdep, whatever) for
something, it levels an EAPI check, and then sets DEPENDENCIES.
Meanwhile, until it moves it's minimal EAPI to one requiring
DEPENDENCIES, they can use the old syntax and have it stacked.
Basically, either we can have git.eclass (for example) doing:
if has $EAPI 0 1 2 3 4; then
DEPEND=">=dev-util/git-1.6"
else
DEPENDENCIES="dep:build? ( >=dev-util/git-1.6 )"
fi
Or, as long as it's suppporting EAPI's 0 1 2 3 4 and the transition is
still enabled for the actual EAPI it's being used in...
DEPEND=">=dev-util/git-1.6"
Doing this means no eclass code has to maintain EAPI5 dependencies
code and <EAPI5 depends/rdepends in parallel; they can transition to
pure DEPENDENCIES form at their own pace, dependent on their code, and
the EAPIs they support. At some point we state "the transition hack
will be removed in the next EAPI"- giving decent forewarning- then
remove it if it's not an undue dev burden. As for eclasses/ebuilds
that are purely >=EAPI5, they convert to DEPENDENCIES syntax as they
go/have spare cycles.
Bluntly, this approach makes transition pretty painless for the vast
majority of the tree. In the grand scheme of things, this is actually
one of the simplest/cleanest migration EAPI will see I suspect.
There really isn't a sane argument to be made against this beyond
"screw it, just make the devs convert immediately and damn the costs"
(which I don't view as sane).
Either way, strongly get the feeling you're arguing purely because it
had the term DEPENDENCIES in it...
~harring
