Take a hypothetical set of dependencies: foo-bar/x-5.0.ebuild has DEPEND="foo-bar/y-5.0" foo-bar/x-4.0.ebuild has DEPEND="foo-bar/y-4.0" foo-bar/x-3.0.ebuild has DEPEND="foo-bar/z" foo-bar/y-5.0.ebuild has DEPEND="foo-bar/x-5.0" foo-bar/y-4.0.ebuild has DEPEND="foo-bar/x-4.0" foo-bar/y-3.0.ebuild has DEPEND="foo-bar/x-3.0" If you try "emerge y", emerge will fail to identify the cyclical dependency between foo-bar/x-5.0 and foo-bar/y-5.0 and attempt to build them anyway. Of course, the ebuild is likely to fail (i.e., missing command or library). The same problem would ocurr if you ran "emerge =y-4.0". However, running "emerge =y-3.0" will successfully merge y-3.0, with x-3.0 and z as dependencies. So: (1) it seems that portage does not identify cyclical dependencies, and (2) portage does not automatically roll-back version numbers in order to find a version/upgrade path to satisfy the dependencies I know cyclical dependencies aren't supposed to ocur in the portage tree. But, particularly as a result of having certain USE flags set, this can happen. Example: USE="perl nls" emerge -e system # <-- try without perl installed IMHO, portage should be able to identify these DEPEND loops and "shuffle" version numbers (ideally, rebuilding packages as necessary) to reach the requested state. This behavior has been noticed using portage-2.0.54 -march=pentium3 2006.0 portage-20060122.
*** This bug has been marked as a duplicate of 16365 ***
