1 |
On Fri, Mar 19, 2010 at 04:23:31AM -0500, Dale wrote: |
2 |
> OK. Right now, as you type this, what package depends on python-3 and |
3 |
> won't work with python-2? Anything at all? If it is nothing, then why |
4 |
> install it? |
5 |
|
6 |
To some degree it's the users choice which python version they choose |
7 |
to settle on- a simple server system doing file sharing could actually |
8 |
be py3k via portage/pkgcore both supporting py3k (including their |
9 |
dependencies). |
10 |
|
11 |
As for py3k only pkgs, I'd bet 3to2 is py3k only... it's worth noting |
12 |
that some new libs are targeting py3k only also (I don't agree with |
13 |
that, but it's upstreams choice). |
14 |
|
15 |
|
16 |
> Since python-3 is not what the system is using, it's not getting used |
17 |
> even if it is installed. So as I mentioned in another reply, portage is |
18 |
> installing something and it is just sitting there doing nothing. What |
19 |
> is the point in that? |
20 |
|
21 |
Mask the freaking package already. The time people have extended in |
22 |
bitching about this *literally* exceeds the time to type |
23 |
|
24 |
mkdir -p /etc/portage && \ |
25 |
echo '>=dev-lang/python-3' >> /etc/portage/package.mask |
26 |
|
27 |
|
28 |
If you consider masking it to be that horrible (or want to keep |
29 |
expending time), fine- then please do what Betelgeuse has |
30 |
suggested in IRC and raid from the ruby eclass the USE_EXPAND'd |
31 |
ruby_targets trickery and integrate that into the python eclass [1]. |
32 |
Via that (and a lot of ebuild cleanup) users could explicitly specify |
33 |
the python versions they want targeted and it would properly be |
34 |
represented in the depgraph. |
35 |
|
36 |
~harring |
37 |
|
38 |
[1] Note that python.eclass already has something *roughly* similar to |
39 |
this, but 1) it's not USE based, 2) no one aparently knows about it, |
40 |
3) from what I've seen most ebuilds haven't really been converted to |
41 |
handle this properly (yet). |