For some reason this stage3 has python-2.7 built with almost no USE flags enabled, while python-3.1 is fine. This is causing issues when users first emerge something depending on dev-lang/python[xml] as the 3.1 (non-active) version has it enabled so emerge doesn't complain. But this is a side-issue, I'm pretty sure something went wrong that python:2.7 hasn't been built with the normal flags. Reproducible: Always Steps to Reproduce: 1. unpack stage3-amd64-20120112.tar.bz2, chroot 2. cat /var/db/pkg/dev-lang/python-2.7.2-r3/USE 3. cat /var/db/pkg/dev-lang/python-3.1.4-r3/USE Actual Results: # cat /var/db/pkg/dev-lang/python-2.7.2-r3/USE amd64 build elibc_glibc kernel_linux multilib userland_GNU wide-unicode #cat /var/db/pkg/dev-lang/python-3.1.4-r3/USE amd64 elibc_glibc gdbm ipv6 kernel_linux multilib ncurses readline ssl threads userland_GNU wide-unicode xml Expected Results: same USE flags, or close
I just confirmed this on a hardened amd64 stage3 built on my server.
BTW I'm seeing the same thing in install-amd64-minimal-20120119, of course it doesn't break much besides mirrorselect there.
So, python:2.7 isn't a dep of @system when USE=build isn't set, so that's why it's not rebuilt with proper flags for stage3. In fact it's *almost* depclean-eligible, but depclean actually does now check for active python version & doesn't unmerge 2.7. Otherwise we'd be having stage3's with python-3.1 only.
I guess my question is, if python-2.7 isn't explicitly needed by anything in stage3, why do we ship it at all? Yes I'm aware of how scary 3.x sounds as the main and only python version installed, but so what? If something *really* needs 2.x, it would be a dep, right? Either set 3.x as main/default python and let 2.x be dropped from stage3, or make something in stage3 depend explicitly on 2.x
Sounds fineish to me.
Given the choices (although I am not happy about python slotting in general), I'd say to add python-2 to the system set then announce the intentions to remove it from stage3 in 30/60/etc days.
@python: Are we ready for a python3 only stage? How much breakage on non-stage packages do you anticipate?
(In reply to comment #7) > @python: > Are we ready for a python3 only stage? How much breakage on non-stage packages > do you anticipate? Given this bug, nothing in stage3 *depends* on python-2. If the RDEPEND variables are correct, there can be no breakage. Right?
(In reply to comment #7) > @python: > Are we ready for a python3 only stage? How much breakage on non-stage packages > do you anticipate? I think our deps should be okay. There will probably be some things that break. I think we should try it. We can always revert it, right? BTW, does this stage3 ship python3 as python, too, or just as python3?
More funky behavior from this "unneeded" python-2.7 issue on a fresh stage3-- # emerge -pv gentoolkit These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-portage/gentoolkit-0.3.0.4-r5 0 kB [uninstall ] dev-lang/python-2.7.2-r3 USE="build (wide-unicode) -berkdb -doc -examples -gdbm -ipv6 -ncurses -readline -sqlite -ssl -threads -tk -wininst -xml" [blocks b ] >=dev-lang/python-2.6[-xml] (">=dev-lang/python-2.6[-xml]" is blocking app-portage/gentoolkit-0.3.0.4-r5) Total: 1 package (1 new, 1 uninstall), Size of downloads: 0 kB Conflict: 1 block # When run for real, the emerge actually bombs out during gentoolkit's setup phase when it sees an installed python version doesn't have xml enabled, but this is another thing that (imho) new users should not have to deal with.
This bug should be fixed in new stages, which won't have Python 2: 18 Feb 2012; Zac Medico <zmedico@gentoo.org> portage-2.1.10.41.ebuild, portage-2.1.10.44.ebuild, portage-2.1.10.46.ebuild, portage-2.1.10.47.ebuild, portage-2.2.0_alpha84.ebuild, portage-2.2.0_alpha86.ebuild, portage-2.2.0_alpha87.ebuild, portage-9999.ebuild: Remove special USE=build python dependencies, since they no longer function correctly as reported in bug #399331.
I had some time to play with stage3-i686-20120221.tar.bz2 and it seems to be going very well. It was indeed built with only python-3.1.4, which is properly active/default, and works fine on portage. The few python2-only apps I tried picked up python2 as a proper dep, and installed & ran fine. Well there was a little hiccup with mirrorselect but zmedico has fixed it already. I also took a look at install-x86-minimal-20120221.iso, and while it does still have python-2.7.2 installed & active, but it seems to have been built w/ proper USE so mirrorselect (the only python-using tool on the installcd, that I can see) works fine.
Latest amd64 stage is now fixed as well, time to close bug?
This was fixed some time ago.
