On 03/10/10 11:36, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-03-08 22:28:16 William Hubbs napisał(a):
>> On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote:
>>> No, it won't. To prove it, I've just tested with a stable stage3
>>> containing portage-2.1.7.x. Here are the steps:
>>>
>>> 1) extract stable stage3 and chroot into it
>>> 2) mkdir /etc/portage&&  echo "dev-lang/python ~*">>
>>> /etc/portage/package.keywords
>>> 3) Run `emerge -pu --deep=1 portage`:
>>>     These are the packages that would be merged, in order:
>>>
>>>     Calculating dependencies... done!
>>>     [ebuild     UD] sys-apps/sandbox-1.6-r2 [2.2]
>>>     [ebuild     UD] app-shells/bash-4.0_p35 [4.0_p37]
>>>     [ebuild     U ] dev-lang/python-2.6.4-r1 [2.6.4]
>>>
>>> If you try `emerge -puD world` then you will see
>>> dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python
>>> atoms in the cracklib and libxml2 dependencies. However, in
>>> portage-2.1.7.x (current stable), there is support for
>>> pseudo-version-ranges in dependencies. This allows you use a
>>> dependency like<dev-lang/python-3 in a package that doesn't support
>>> python3, and that will prevent it from getting pulled into the
>>
>> According to this, we can fix all of the dependencies in the tree then
>> stabilize python3 without having any issues, so I would vote for this
>> route, because it still oinsures that the stable tree will work
>> together.
>
> Almost everybody has at least 1 package installed which supports both Python 2
> and Python 3 and depends on dev-lang/python without version specification,
> so Python 3 would be pulled into dependency graph, so fixing of dependencies
> doesn't need to block stabilization of Python 3.
>

What about introducing a python3 USE flag? Seems like that would keep 
everybody happy.

--Ravi