As you may or may not know, the Python package that the Prefix tree
contains is far from similar to the original from the gentoo-x86 tree.
Reason for this is first and foremost a good bunch (around 33 iirc) of
patches that need to be applied either to fix bugs, or to change
behaviour so it makes sense. An example of the latter is to fix the
code to actually *do* use readline when available on OSX 10.4, instead
of forcefully disabling it without looking, just because by definition
it is supposed not to work. Patches like those simply contradict the
vision of Python's upstream. Sometimes that's just because "yes we can"
in Prefix, sometimes it's just because hardcoding known configurations
isn't always what we call the most optimal choice.
Anyway, let me assure you that the road to getting to a working
python-2.4 was terrible. Doing it all again to get a working python-2.5
was horrible. And of course starting from scratch again to get a
working python-2.6 including a framework build on OSX was a hell. This
is also the major reason why Prefix doesn't do python-3.x (yet). Since
that version isn't widely usable anyway, the cost of getting it to work
is too high to be acceptable, especially since each new version requires
so much extra work ... and frustration.
Of course we're not happy with this. We have a bloated ebuild,
non-trivial and big. But what can we do? Unfortunately we need a
working Python, also in Prefix.
It seems that the python team thinks about the same of the ebuilds, and
hence doesn't want to have it . In a way I can understand, it's no
fun. But on the other hand, it's not like we did this for the fun of
it. But alas, they don't like the changes, which means a major problem
for us as Prefix people. A blocker actually.
So what should we do? One of the differences between Prefix python and
gx86 python is the addition of the "aqua" USE-flag. We need it for some
packages, in particular for the last remaining package in dev-python in
the Prefix tree: wxpython. So always keeping an overlay version won't
work in this respect. What are the alternatives? Create a
python-prefix package, that is under maintenance of the prefix team?
Would mean we have to fix depstrings all over the place, but as last
Gentoo on a different level