| 1 |
On 03/05/2010 11:26 AM, Duncan wrote: |
| 2 |
> Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted: |
| 3 |
> |
| 4 |
>> On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: |
| 5 |
>>> Now on more serious note, ideally python could be treated just like any |
| 6 |
>>> other non-leaf package (in dependency tree), just like library. In such |
| 7 |
>>> case it's completely reasonable to stabilize the newest version of such |
| 8 |
>>> 'library', especially when it's slotted and doesn't conflict in any way |
| 9 |
>>> with the rest. However, because of being used by package manager, |
| 10 |
>>> python is leaf application really and it's going to be immediately |
| 11 |
>>> pulled for everyone. |
| 12 |
>> |
| 13 |
>> It won't be pulled in by sys-apps/portage dependencies which look like |
| 14 |
>> this: |
| 15 |
>> |
| 16 |
>> || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 |
| 17 |
>>> =dev-lang/python-3 ) |
| 18 |
>> |
| 19 |
>> If you already have python:2.6 installed then it will not pull in a new |
| 20 |
>> slot. |
| 21 |
> |
| 22 |
> Won't emerge -aNuD pull it in anyway, even in a new slot, since portage |
| 23 |
> says it can use it? I know I use that, so I'm always updated all the way |
| 24 |
> thru the system, not just at the leaves. |
| 25 |
|
| 26 |
No, it won't. To prove it, I've just tested with a stable stage3 |
| 27 |
containing portage-2.1.7.x. Here are the steps: |
| 28 |
|
| 29 |
1) extract stable stage3 and chroot into it |
| 30 |
2) mkdir /etc/portage && echo "dev-lang/python ~*" >> |
| 31 |
/etc/portage/package.keywords |
| 32 |
3) Run `emerge -pu --deep=1 portage`: |
| 33 |
These are the packages that would be merged, in order: |
| 34 |
|
| 35 |
Calculating dependencies... done! |
| 36 |
[ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] |
| 37 |
[ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] |
| 38 |
[ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] |
| 39 |
|
| 40 |
If you try `emerge -puD world` then you will see |
| 41 |
dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python |
| 42 |
atoms in the cracklib and libxml2 dependencies. However, in |
| 43 |
portage-2.1.7.x (current stable), there is support for |
| 44 |
pseudo-version-ranges in dependencies. This allows you use a |
| 45 |
dependency like <dev-lang/python-3 in a package that doesn't support |
| 46 |
python3, and that will prevent it from getting pulled into the |
| 47 |
dependency graph. |
| 48 |
-- |
| 49 |
Thanks, |
| 50 |
Zac |
Archives