Summary: | Emerge can't handle circular dependencies | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Hiel Van Campen <hielvc> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cesarb, craig.lawson, denys.duchier, gentoo, jason, johnm, news, oldium.pro, re-vax, sascha-gentoo-bugzilla, sn.ml, virginsnow |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 147766 | ||
Bug Blocks: | 155723, 147007 | ||
Attachments: | Ignore blockers on packages about to be updated |
Description
Hiel Van Campen
2003-02-25 14:40:38 UTC
This just a question which about the troubles with dependencies. The same prob that catalyst should solve. SO close this sucker! Have a great New Years hielvc Still does ;^) but not quit as often,those nasty dependence trees. *** Bug 11272 has been marked as a duplicate of this bug. *** *** Bug 16538 has been marked as a duplicate of this bug. *** *** Bug 37453 has been marked as a duplicate of this bug. *** *** Bug 41019 has been marked as a duplicate of this bug. *** *** Bug 44632 has been marked as a duplicate of this bug. *** *** Bug 108664 has been marked as a duplicate of this bug. *** (In reply to comment #8) > *** Bug 108664 has been marked as a duplicate of this bug. *** May I ask what the difficulty is in _noticing_ a circularity in the dependency graph and informing the user of it? I noticed something that looks odd in the computation on the depgraph: % emerge -e cyrus-sasl -pv --debug gives me (among a lot of output): Parent: ebuild / net-nds/openldap-2.2.28-r1 merge Depstring: >=sys-libs/ncurses-5.1 tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) ssl? ( >=dev-libs/openssl-0.9.6 ) readline? ( >=sys-libs/readline-4.1 ) sasl? ( >=dev-libs/cyrus-sasl-2.1.7-r3 ) odbc? ( dev-db/unixODBC ) slp? ( >=net-libs/openslp-1.0 ) perl? ( >=dev-lang/perl-5.6 ) samba? ( >=dev-libs/openssl-0.9.6 ) kerberos? ( virtual/krb5 ) berkdb? ( >=sys-libs/db-4.2.52_p1 ) !berkdb? ( gdbm? ( >=sys-libs/gdbm-1.8.0 ) !gdbm? ( >=sys-libs/db-4.2.52_p1 ) ) >=sys-devel/libtool-1.5.18-r1 >=sys-apps/sed-4 !bootstrap? ( sys-devel/patch ) !bootstrap? ( sys-devel/patch ) >=sys-libs/ncurses-5.1 tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) ssl? ( >=dev-libs/openssl-0.9.6 ) readline? ( >=sys-libs/readline-4.1 ) sasl? ( >=dev-libs/cyrus-sasl-2.1.7-r3 ) odbc? ( dev-db/unixODBC ) slp? ( >=net-libs/openslp-1.0 ) perl? ( >=dev-lang/perl-5.6 ) samba? ( >=dev-libs/openssl-0.9.6 ) kerberos? ( virtual/krb5 ) berkdb? ( >=sys-libs/db-4.2.52_p1 ) !berkdb? ( gdbm? ( >=sys-libs/gdbm-1.8.0 ) !gdbm? ( >=sys-libs/db-4.2.52_p1 ) ) Candidates: ['>=sys-libs/readline-4.1', '>=dev-libs/openssl-0.9.6', 'dev-db/unixODBC', '>=net-libs/openslp-1.0', '>=sys-devel/libtool-1.5.18-r1', '>=sys-apps/tcp-wrappers-7.6'] notice how cyrus-sasl is missing from the "Candidates" while: % emerge -e openldap -pv --debug gives me: Parent: ebuild / net-nds/openldap-2.2.28-r1 merge Depstring: >=sys-libs/ncurses-5.1 tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) ssl? ( >=dev-libs/openssl-0.9.6 ) readline? ( >=sys-libs/readline-4.1 ) sasl? ( >=dev-libs/cyrus-sasl-2.1.7-r3 ) odbc? ( dev-db/unixODBC ) slp? ( >=net-libs/openslp-1.0 ) perl? ( >=dev-lang/perl-5.6 ) samba? ( >=dev-libs/openssl-0.9.6 ) kerberos? ( virtual/krb5 ) berkdb? ( >=sys-libs/db-4.2.52_p1 ) !berkdb? ( gdbm? ( >=sys-libs/gdbm-1.8.0 ) !gdbm? ( >=sys-libs/db-4.2.52_p1 ) ) >=sys-devel/libtool-1.5.18-r1 >=sys-apps/sed-4 !bootstrap? ( sys-devel/patch ) !bootstrap? ( sys-devel/patch ) >=sys-libs/ncurses-5.1 tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) ssl? ( >=dev-libs/openssl-0.9.6 ) readline? ( >=sys-libs/readline-4.1 ) sasl? ( >=dev-libs/cyrus-sasl-2.1.7-r3 ) odbc? ( dev-db/unixODBC ) slp? ( >=net-libs/openslp-1.0 ) perl? ( >=dev-lang/perl-5.6 ) samba? ( >=dev-libs/openssl-0.9.6 ) kerberos? ( virtual/krb5 ) berkdb? ( >=sys-libs/db-4.2.52_p1 ) !berkdb? ( gdbm? ( >=sys-libs/gdbm-1.8.0 ) !gdbm? ( >=sys-libs/db-4.2.52_p1 ) ) Candidates: ['>=sys-apps/tcp-wrappers-7.6', '>=dev-lang/perl-5.6', '>=dev-libs/openssl-0.9.6', 'dev-db/unixODBC', '>=sys-libs/db-4.2.52_p1', '>=net-libs/openslp-1.0', '>=sys-devel/libtool-1.5.18-r1', 'sys-devel/patch', '>=sys-libs/ncurses-5.1', '>=sys-libs/readline-4.1', '>=sys-apps/sed-4', '>=dev-libs/cyrus-sasl-2.1.7-r3'] where it correctly appears. I have the sinking feeling that emerge does not actually build a correct and complete depgraph :-/ Can anyone enlighten me as to what the core problem is? The core problem is that emerge does not actually build a correct and complete depgraph. ;) Instead it assumes that any package that already exists in the graph has had its dependencies taken care of. Based on this (incorrect) assumption, it then pulls leaf packages from the graph one at a time in the order that they were added. (In reply to comment #11) is this dep_zapdeps's doing? Maybe, instead of discarding dependencies, it should return a pair (deps_todo,deps_done) so that depgraph building can add appropriate edges for the deps_done without processing them again. ... or have I completely misunderstood the problem? emerge, line 928. (In reply to comment #13) > emerge, line 928. Interesting, but I don't think that explains the missing "Candidates". Does it? *** Bug 93795 has been marked as a duplicate of this bug. *** *** Bug 122432 has been marked as a duplicate of this bug. *** OK, so this is a known limitation. Is there a known workaround? Is there any kind of test to predict when an merge will fail due to circular dependency? (emerge -p won't tell you because it doesn't actually invoke the ebuild) How do the devs get from stage2 to stage3, anyway, given this limitation? I have trouble imagining devs tweaking package.mask every time they want to build a stage3 tarball. There's *got* to be a workaround! I'm really starting to be desperate with this "feature" (and other features). I just now tried to update my system, I have the newest portage 2.1.1_pre2-r6 and I tried to update the system and stopped with java-config-1.2.11 update. java-config depends (RDEPENDS) on java-config-wrapper and java-config-wrapper depends (DEPENDS) on java-config. Update could run perfectly, but... # emerge -uav --oneshot =dev-java/java-config-1.3.0-r2 [blocks B ] <dev-java/java-config-1.3 (is blocking dev-java/java-config-wrapper-0.9-r5) [ebuild N ] dev-java/java-config-wrapper-0.9-r5 4 kB [ebuild U ] dev-java/java-config-1.3.0-r2 [1.2.11-r1] 13 kB or when I start with --tree # emerge -uav --tree --oneshot =dev-java/java-config-1.3.0-r2 [blocks B ] <dev-java/java-config-1.3 (is blocking dev-java/java-config-wrapper-0.9-r5) [ebuild U ] dev-java/java-config-1.3.0-r2 [1.2.11-r1] 13 kB [ebuild N ] dev-java/java-config-wrapper-0.9-r5 4 kB The order is different with tree and without tree. The update without the specified version selects java-config-2*, but it does not update java-config-1*. "Deep" update of world selects both versions, but in wrong order (as for emerge without --tree): # emerge -uav --deep world [blocks B ] <dev-java/java-config-1.3 (is blocking dev-java/java-config-wrapper-0.9-r5) ... [ebuild N ] dev-java/java-config-wrapper-0.9-r5 4 kB [ebuild NS ] dev-java/java-config-2.0.26-r3 14 kB [ebuild U ] dev-java/java-config-1.3.0-r2 [1.2.11-r1] 13 kB Heh? I really do not want to solve those problems by hand again and again every year... (In reply to comment #14) > I don't think that explains the missing "Candidates". Those missing "Candidates" are now added to the digraph in >=portage-2.1.1_pre3-r5 (see bug 126748). It still isn't able to automatically negotiate circular dependencies but at least they should be reported correctly so that a bug can be filed. (In reply to comment #19) > Those missing "Candidates" are now added to the digraph Well, more of them, anyway. As shown by bug 144527, there are still more missing candidates. I'm thinking about adding a boolean parameter to dep_check and dep_zapdeps so that dep_check will be able to return all of the selected atoms, even the ones that are already satisfied. That will allow us to build a complete digraph and detect circular deps that currently go undetected. Created attachment 97335 [details, diff] Ignore blockers on packages about to be updated Processes blockers after the dep graph has been built and removes any blockers that only apply to packages that are about to be updated. This fixes the scenario listed in comment #18. This patch applies on top of the patches from bug #147766 (In reply to comment #21) > Ignore blockers on packages about to be updated This patch is in svn r4486. It does leave the system in a slightly inconsistent state for a period of time. I think it's well worth it though, considering that is solves a common case of bug 79606 in a very logical way. If the system is left in an inconsistent state, the user will eventually receive a complaint from emerge if necessary. This bug is solved by the patches from bug 147766 which have been released in 2.1.2_pre1-r1. |