On Fri, Mar 19, 2010 at 04:23:31AM -0500, Dale wrote:
> OK.  Right now, as you type this, what package depends on python-3 and 
> won't work with python-2?  Anything at all?  If it is nothing, then why 
> install it?

To some degree it's the users choice which python version they choose 
to settle on- a simple server system doing file sharing could actually 
be py3k via portage/pkgcore both supporting py3k (including their 

As for py3k only pkgs, I'd bet 3to2 is py3k only... it's worth noting 
that some new libs are targeting py3k only also (I don't agree with 
that, but it's upstreams choice).

> Since python-3 is not what the system is using, it's not getting used 
> even if it is installed.  So as I mentioned in another reply, portage is 
> installing something and it is just sitting there doing nothing.  What 
> is the point in that?

Mask the freaking package already.  The time people have extended in 
bitching about this *literally* exceeds the time to type

mkdir -p /etc/portage && \
echo '>=dev-lang/python-3' >> /etc/portage/package.mask

If you consider masking it to be that horrible (or want to keep 
expending time), fine- then please do what Betelgeuse has 
suggested in IRC and raid from the ruby eclass the USE_EXPAND'd 
ruby_targets trickery and integrate that into the python eclass [1].  
Via that (and a lot of ebuild cleanup) users could explicitly specify 
the python versions they want targeted and it would properly be 
represented in the depgraph.


[1] Note that python.eclass already has something *roughly* similar to 
this, but 1) it's not USE based, 2) no one aparently knows about it, 
3) from what I've seen most ebuilds haven't really been converted to 
handle this properly (yet).

Attachment: pgpfuTlCbt1ph.pgp
Description: PGP signature

Reply via email to