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
