| 1 |
As another user, I have an interesting thought: Keep *_TARGETS and |
| 2 |
*_COMPAT, but add useflags called "[python|php|ruby]-compat-testing", |
| 3 |
which is at least use.stable.mask'ed (possibly straight-up |
| 4 |
use.mask'ed), to any ebuild that uses *_COMPAT. Setting the |
| 5 |
appropriate useflag would allow such ebuilds to build against any |
| 6 |
interpreter version listed in the appropriate *_TARGETS variable, even |
| 7 |
those the ebuild doesn't explicitly support. |
| 8 |
|
| 9 |
To help with keeping things reasonable, support for both ranges and |
| 10 |
negation could be added to *_COMPAT. This way, for example, an ebuild |
| 11 |
for a Python 2.7-only program, could specify PYTHON_COMPAT="2.7 |
| 12 |
->=3.0", and the ebuild for a ruby app that's known to be broken in |
| 13 |
2.2 but works fine in both 2.1 and 2.3 could specify |
| 14 |
RUBY_COMPAT="-2.2". Obviously, the *-compat-testing flags should not |
| 15 |
allow building against a known-incompatible TARGET if this is |
| 16 |
implemented. :) |
| 17 |
|
| 18 |
This keeps the benefits of *_COMPAT and *_TARGETS while allowing |
| 19 |
people to test a new python/php/ruby interpreter without having to |
| 20 |
manually edit dozens (potentially hundreds or thousands) of ebuilds. |
| 21 |
|
| 22 |
--James |
Archives