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 dependencies). 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. ~harring [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).
pgpfuTlCbt1ph.pgp
Description: PGP signature
