Hello, all. I have committed today the eclass support code for python-exec:2, and first package.mask-ed version of it. The benefits of the new solution were explained in the earlier RFC mail [1]. Now for the migration plan.
The eclasses cleanly support either version of the wrapper. They use :=
dep and a has_version check to use the latest slot installed. That is,
you won't get the new behavior until you install python-exec:2.
Afterwards, the packages should cleanly switch on next rebuild.
We're planning on keeping python-exec:2 in package.mask for a while
for testing, then unleash it to the ~arch population. When tested well
enough, we will stabilize it and start deprecating the old wrapper. For
most of our users, this process should be seamless and pain-free.
However, we know of some ebuilds that are going to be broken with
the new wrapper since they rely too much on wrapping mechanism [2].
Since many of those can't really be fixed much better, those ebuilds
will be 'locked' at a single version of the wrapper.
If you know that a package does not work with python-exec:2,
the following snippet needs to be added to it:
DEPEND="dev-python/python-exec:0"
_PYTHON_WANT_PYTHON_EXEC2=0
This will ensure keeping the old wrapper around and override
the has_version check to force using the old wrapper.
If you know that your package works only with python-exec:2,
use the following snippet instead:
DEPEND="dev-python/python-exec:2"
No override is necessary here, since install of new wrapper will cause
the eclass to automatically switch to it. But please note that your
package's visibility/keywords will need to follow python-exec:2.
All testing will be appreciated. Enjoy.
[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/88095
[2]:https://bugs.gentoo.org/show_bug.cgi?id=484398
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
