Summary: | stage3-amd64-20120112 has python:2.7 built with USE="build" only | ||
---|---|---|---|
Product: | Gentoo Release Media | Reporter: | Ben Kohler <bkohler> |
Component: | Stages | Assignee: | Gentoo Release Team <releng> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bkohler, djc, gentoo, kfm, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | a) add python-2 to @system OR b) let python-2 be dropped from stage3 | ||
Package list: | Runtime testing required: | --- |
Description
Ben Kohler
2012-01-18 22:29:10 UTC
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. |