Hello,

Since we're practically ready to start building pypy-bin packages, we
should address the compatibility within eclasses.

I'm sending six patches that fix all the Python eclasses (-r1, -ng
and the old one) to support pypy-bin. It should be noted that some
ebuilds which use ugly unsupported hackery (sys-apps/portage) will
still need to be updated by hand.

And all users who had pypy enabled before will need to rebuild all
the packages that depend on it, or hack their *DEPEND in vardb to allow
pypy-bin.

Patches will be sent as replies to this mail. Short summary follows.


python-any-r1.eclass:

1) use PYTHON_PKG_DEP for generating deps

I must have missed it when converting the other two eclasses.

2) replace has_version with simple '-x' check

That makes it simpler, faster and compatible with PYTHON_PKG_DEP
becoming any-of dep.


python-utils-r1.eclass:

3) simple reordering of PYTHON_PKG_DEP

4) generate any-of dep for || ( pypy pypy-bin )

Which basically makes all the eclasses compatible.


python-distutils-ng.eclass:

5) add any-of dep to *DEPEND.

Although it's doomed, it's fairly easy to add the support to it.


python.eclass:

6) hack python_get_implementation_package() for pypy-bin

It's not used anywhere but in the eclass itself. It's used solely for
passing into 'has_version' to do integrity checks or PYTHON_USE_WITH
checks in ancient EAPIs.

I don't think it's worth to address this deprecated eclass thoroughly.
Therefore, the patch just uses has_version to see if pypy-bin is
installed, and outputs 'pypy-bin' or 'pypy' atom appropriately.

Also, I don't see any place outputting pypy dep. I guess it just
doesn't do it.

-- 
Best regards,
Michał Górny