I tried installing a new Gentoo system using the stage3 dated 2012-12-10 for AMD64. I'd like it to be a testing system, so I have added ACCEPT_KEYWORDS="~amd64" to make.conf. In this situation, I'm not able to install python-2.7.3-r3 because of circular dependencies. Basically version 2.7.3-r3 wants python-2.6.8-r1, but this latter one wants python-2.7.3-r3. There's a workaround: installing python-2.7.3-r2 instead of python-2.7.3-r3, and then updating to 2.7.3-r3, as python-2.7.3-r2 does not need an already existing python 2 instance. I noticed there are lots of differences between 2.7.3-r2 and 2.7.3-r3 ebuilds, and it's not easy for me to find out what change is responsible for this behaviour. Reproducible: Always # emerge -pv =python-2.7.3-r3 These are the packages that would be merged, in order: Calculating dependencies ... done! [nomerge ] dev-lang/python-2.7.3-r3:2.7 [3.2.3:3.2] USE="gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -berkdb -build -doc -examples -sqlite -tk -wininst" [ebuild NS ] dev-lang/python-2.6.8-r1:2.6 [3.2.3:3.2] USE="gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -berkdb -build -doc -examples -sqlite -tk -wininst" 10,885 kB [ebuild NS ] dev-lang/python-2.7.3-r3:2.7 [3.2.3:3.2] USE="gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -berkdb -build -doc -examples -sqlite -tk -wininst" 11,531 kB Total: 2 packages (2 in new slots), Size of downloads: 22,415 kB * Error: circular dependencies: (dev-lang/python-2.7.3-r3::gentoo, ebuild scheduled for merge) depends on (dev-lang/python-2.6.8-r1::gentoo, ebuild scheduled for merge) (buildtime) (dev-lang/python-2.7.3-r3::gentoo, ebuild scheduled for merge) (buildtime) * Note that circular dependencies can often be avoided by temporarily * disabling USE flags that trigger optional dependencies. --------------- # emerge =python-2.7.3-r2 These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild NS ] dev-lang/python-2.7.3-r2:2.7 [3.2.3:3.2] USE="gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -berkdb -build -doc -examples -sqlite -tk -wininst" 11,531 kB Total: 1 package (1 in new slot), Size of downloads: 11,531 kB
This doesn't seem like a releng bug to me, but a python bug. Thus, I'm reassigning. FWIW, the stages only have python-3 as no package in the system set has a dependency on python-2.
Created attachment 332696 [details] IRC log from 2012-11-26 I have attached an IRC log from 2012-11-26 in which Arfrever explains that under some obscure circumstances involving backported patches, python2.7 actually needs python2 to bootstrap itself. Given that we do not currently patch any of the files he mentions, I think we can safely remove python-any-r1.eclass from the dev-lang/python ebuilds. We just need to be careful about patching. @mgorny: Thoughts?
(In reply to comment #2) > Created attachment 332696 [details] > IRC log from 2012-11-26 > > I have attached an IRC log from 2012-11-26 in which Arfrever explains that > under some obscure circumstances involving backported patches, python2.7 > actually needs python2 to bootstrap itself. > > Given that we do not currently patch any of the files he mentions, I think > we can safely remove python-any-r1.eclass from the dev-lang/python ebuilds. > We just need to be careful about patching. > > @mgorny: Thoughts? If you can make sure this is not the case in our ebuilds, feel free to comment it out. I'd just leave a trace of it so people would know what to do whenever such patches actually need to be applied. (In reply to comment #1) > This doesn't seem like a releng bug to me, but a python bug. Thus, I'm > reassigning. > FWIW, the stages only have python-3 as no package in the system set has a > dependency on python-2. I'd say this is not a good thing for our users, since our users usually prefer or even need python-2. And bootstrapping python-3 with python-2 is possible, unlike the other way around. Of course, bootstrapping is probably not needed right now. But well, with python-r1 migration the system set is likely to get a clear dep on python2.7 soon.
(In reply to comment #3) > If you can make sure this is not the case in our ebuilds, feel free to > comment it out. I'd just leave a trace of it so people would know what to do > whenever such patches actually need to be applied. I have just verified that I can build python2.{5,7} successfully after removing python-any-r1 and my /usr/bin/python symlink. I think this confirms that the current python ebuilds do not require python to be installed. I propose that if we ever apply a patch which requires bootstrapping, we should pre-generate the new files and include them in said patch. I will make an annotation in the ebuild stating this. This would probably be more of an issue if we still had pre-release ebuilds in the tree, or a live ebuild. We don't really back-port changes these days.
This should be fixed now.
