On Mon, 7 Dec 2015 15:36:30 -0500 Mike Gilbert wrote: > On Sun, Dec 6, 2015 at 2:03 PM, Michał Górny wrote: > > Hi, > > > > Here's another patchset. Mostly fixups inspired by multilib-build.eclass > > changes with a few little additions. > > > > Changes: > > > > 1. eclass-set variables are now read-only, > > Sounds ok, but might break some ebuilds. > > > 2. 'unset -f' is used to unset temporary & local functions, > > 3. implementations are reordered for sane order. > > > > I've tested this with a few dozen random distutils-r1, python-r1, > > python-any-r1 and python-single-r1 packages. However, for > > the implementation reorder a larger tinderbox run would be appreciated. > > > > As explained in the commit, the reorder may influence files installed by > > a package, and implementation selected by python_setup(). This should > > not cause issues for correctly written ebuilds, and should help us find > > those that are not correctly written ;-). > > > > In other words, we're finally considering Python 3.x preferred over > > Python 2.x. > > That could be a significant change, and I do expect that this will > break some ebuilds. > > Any easy way to test this first? Or should we just be ready for the bug reports? Not an easy. We could try some tinderboxing with USE='doc python'. Or just grep ebuilds for python_export_best calls and plain python_setup calls, and see if someone didn't assume it will always prefer python2. REQUIRED_USE with python_gen_useflags may be a suggestion too. So I'd go for waiting for bug reports. Or maybe doing the change conditionally to EAPI 6 for improved confusion ;-). -- Best regards, Michał Górny