From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Nnhho-0007D9-Kz for garchives@archives.gentoo.org; Sat, 06 Mar 2010 00:17:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1F421E0CC2; Sat, 6 Mar 2010 00:17:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0DD75E0C0C for ; Sat, 6 Mar 2010 00:17:08 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id A88851B4022 for ; Sat, 6 Mar 2010 00:17:07 +0000 (UTC) Message-ID: <4B919F98.2090208@gentoo.org> Date: Fri, 05 Mar 2010 16:19:36 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.7) Gecko/20100215 Thunderbird/3.0.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item References: <201003041923.17749.Arfrever@gentoo.org> <20100305021444.768724e6@angelstorm> <201003051209.56096.reavertm@gmail.com> <4B90E9ED.6010102@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7a6c965d-3104-481a-871b-a79c70885983 X-Archives-Hash: f100bdcf718f0d6e9be648cec10f18c9 On 03/05/2010 11:26 AM, Duncan wrote: > Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted: > >> On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: >>> Now on more serious note, ideally python could be treated just like any >>> other non-leaf package (in dependency tree), just like library. In such >>> case it's completely reasonable to stabilize the newest version of such >>> 'library', especially when it's slotted and doesn't conflict in any way >>> with the rest. However, because of being used by package manager, >>> python is leaf application really and it's going to be immediately >>> pulled for everyone. >> >> It won't be pulled in by sys-apps/portage dependencies which look like >> this: >> >> || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 >>> =dev-lang/python-3 ) >> >> If you already have python:2.6 installed then it will not pull in a new >> slot. > > Won't emerge -aNuD pull it in anyway, even in a new slot, since portage > says it can use it? I know I use that, so I'm always updated all the way > thru the system, not just at the leaves. 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