Portage fails to merge because of blocked packages, even if the block will be removed during the merge. Calculating dependencies... done! [blocks B ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.3) * snip * [ebuild U ] dev-python/pygtk-2.10.3 [2.8.2] USE="doc* opengl" 2,674 kB [ebuild N ] dev-python/gnome-python-2.16.2 USE="doc -debug" 393 kB [ebuild N ] dev-python/pygobject-2.12.3 USE="doc -debug" 332 kB As you can see, my 2.8 pygtk build is blocking pygobject (which I don't have merged yet). Point is pygtk blocks pygobject because it's <= 2.9. What is crazy here is that portage itself intends to merge pygtk 2.10. Portage doesn't seem to understand that merging pygtk 2.10 will remove the (<= 2.9) block. The merge order should work, but Portage refuses to proceed because of the block. NB: Perhaps there is a good reason for this not to work. However, I think it's a bug in the sense that it _could_ work, but it _doesnt_. Reproducible: Didn't try Steps to Reproduce: 1. Merge pygtk-2.8.2 2. Try to merge dev-util/meld-1.1.4 Actual Results: Portage should fail to merge with the following error message: Calculating dependencies... done! [blocks B ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.3) Expected Results: It should have merged it.
We can add an option giving it permission to uninstall packages automatically. It won't be the default behavior, since users may not want that behavior in every case.
I'm probably missing something here... How exactly is this different from Bug 1343, plus how will unmerging something later on fix the previous depgraph? Or you want to unmerge this and rebuild the depgraph after it's been unmerged?
(In reply to comment #1) > We can add an option giving it permission to uninstall packages automatically. > It won't be the default behavior, since users may not want that behavior in > every case. > How about just the permission to upgrade? It'd be far more sensible..
Umm sorry obviously what needs to happen is the resolver needs to take into account that the package is being upgraded. Will this be fixed with the new resolver? (not spamming)
(In reply to comment #2) > I'm probably missing something here... How exactly is this different from Bug > 1343, That bug is concerned with optimization of a dependency graph for a _final_ state where all of the necessary constraints are satisfied for all of the desired packages. > plus how will unmerging something later on fix the previous depgraph? Or View it as a series of dependency graphs that transition from an initial state to a final state. > you want to unmerge this and rebuild the depgraph after it's been unmerged? The dependency graph gradually evolves over time, one package at a time. Some dependencies can be temporarily unsatisfied during the process of evolution, as long it's accepted that packages with unsatisfied dependencies will be temporarily unusable.
(In reply to comment #5) > The dependency graph gradually evolves over time, one package at a time. Some > dependencies can be temporarily unsatisfied during the process of evolution, as > long it's accepted that packages with unsatisfied dependencies will be > temporarily unusable. sidenote> Sorry to interfere, I'm still trying to follow what's happening around this bug. Precisely. Without knowing the inner details, I feel that perhaps throwing a "blocking action" while encountering the error is too harsh. So, in order to work around that fact, accepting the error, in your own words: > it's accepted that packages with unsatisfied dependencies will be > temporarily unusable. These temporarily unusable packages also have to share this "unusability" with all the packages that depend on it. Careful cycle detection should be made in my opinion - or perhaps are there some facilities laying around doing just that. Cycles are specific, perhaps we should throw the error in that case because we don't know how to merge these packages. (As a sidenote, there must be someone relatively brain-dead who introduced such a potential thing in the portage tree ..) Providing we have a forest of "temporarily disabled packages trees" laying around, a simple counter updated on enable/disable actions provides the ability to know at the end of the process if there are still disabled package trees laying around, which can be considered as an error (or not, but we're not talking features). Waiting for a later-processed package in order to enable again a disabled package tree seems tricky. I don't have any idea on how to do this in regard to portage.
*** Bug 180953 has been marked as a duplicate of this bug. ***
Jakub said this was the same issue. In my case the block comes from a package (idn) that's NOT even installed before running emerge and that's silly. emerge -v bind These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] sys-devel/automake-1.10 873 kB [ebuild U ] net-dns/bind-9.3.4-r3 [9.3.2-r4] USE="idn ldap odbc ssl threads -berkdb -dlz -doc -ipv6 -mysql -postgres -resolvconf% (-selinux)" 5,279 kB [ebuild N ] net-dns/idnkit-1.0 423 kB [blocks B ] net-dns/idnkit (is blocking net-dns/bind-9.3.2-r4) Total: 3 packages (1 upgrade, 1 new, 1 in new slot, 1 block), Size of downloads: 6,574 kB And no, unmerging bind before the update is NOT acceptable. What if it were glibc, kernel or xorg?
(In reply to comment #9) > [ebuild U ] net-dns/bind-9.3.4-r3 [9.3.2-r4] > [ebuild N ] net-dns/idnkit-1.0 > [blocks B ] net-dns/idnkit (is blocking net-dns/bind-9.3.2-r4) Apparently there's a file collision between idnkit and the older bind which installed it's own copy of idnkit. If you don't have collision-protect in FEATURES, then you can probably get away without unmerging bind first. The --nodeps option will cause the blockers and all other dependencies do be ignored. Something like this might work for you: emerge --oneshot --nodeps =sys-devel/automake-1.10 =net-dns/idnkit-1.0 =net-dns/bind-9.3.4-r3
*** Bug 181635 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Precisely. Without knowing the inner details, I feel that perhaps throwing a "blocking action" while encountering the error is too harsh. > > So, in order to work around that fact, accepting the error, in your own words: > > it's accepted that packages with unsatisfied dependencies will be > > temporarily unusable. > These temporarily unusable packages also have to share this "unusability" with all the packages that depend on it. Careful cycle detection should be made in my opinion - or perhaps are there some facilities laying around doing just that. Er aiui cycles aren't hard to detect. Portage may well log this with eqawarn already. Also i think repoman should handle cycle detection. > > Providing we have a forest of "temporarily disabled packages trees" laying around, a simple counter updated on enable/disable actions provides the ability to know at the end of the process if there are still disabled package trees laying around, which can be considered as an error (or not, but we're not talking features). > Er I don't know how that would tie into the resolver. Perhaps the new resolver, wherever it comes from, will answer some of that. > Waiting for a later-processed package in order to enable again a disabled package tree seems tricky. I don't have any idea on how to do this in regard to portage. Nor do I tbh :-) Bear in mind however that the unsatisfied deps are only during the build, so using a binhost will obviate the concerns of enterprise users.
(In reply to comment #10) > (In reply to comment #9) > > [ebuild U ] net-dns/bind-9.3.4-r3 [9.3.2-r4] > > [ebuild N ] net-dns/idnkit-1.0 > > [blocks B ] net-dns/idnkit (is blocking net-dns/bind-9.3.2-r4) > > Apparently there's a file collision between idnkit and the older bind which > installed it's own copy of idnkit. I hope you'll agree with me that it shouldn't be an issue when upgrading, because the target package set provides the same files as the old one. > If you don't have collision-protect in > FEATURES, then you can probably get away without unmerging bind first. The > --nodeps option will cause the blockers and all other dependencies do be > ignored. Something like this might work for you: > > emerge --oneshot --nodeps =sys-devel/automake-1.10 =net-dns/idnkit-1.0 > =net-dns/bind-9.3.4-r3 Well, I don't think suggesting to use --nodeps is a serious answer to this problem.
(In reply to comment #13) > I hope you'll agree with me that it shouldn't be an issue when upgrading, > because the target package set provides the same files as the old one. That may be true in some cases. It's possible to extend the blocker syntax to indicate such cases, but no such syntax is currently supported.
Please translate "Er aiui" since I don't know any meaning for this and I can't even guess ... (In reply to comment #12) > Er aiui cycles aren't hard to detect. Portage may well log this with eqawarn > already. Also i think repoman should handle cycle detection. I'm not too familiar with portage innerds, but are 'eqswarn' some kind of handlable 'exceptions'. Because if they are, it's cycle detection and so we can think of a solution that handles just that. So my question is, are they ? > > Providing we have a forest of "temporarily disabled packages trees" laying > > around, a simple counter updated on enable/disable actions provides the > > ability to know at the end of the process if there are still disabled > > package trees laying around, which can be considered as an error > Er I don't know how that would tie into the resolver. Perhaps the > new resolver, wherever it comes from, will answer some of that. Is there any documentation around the current resolver somewhere, or perhaps there is some knowledge hidden somewhere about that part that you could point out. > > Waiting for a later-processed package in order to enable again a disabled > > package tree seems tricky. I don't have any idea on how to do this in > > regard to portage. > Nor do I tbh :-) Bear in mind however that the unsatisfied deps are > only during the build, so using a binhost will obviate the concerns of > enterprise users. Yep I understand that this problem may seem minor for anyone not concerned by the build. Even if there are good odds that some monkeys will be willing to learn all the nice tricks from the wiki in order to supply our nice enterprise users with the features. True question is : do portage will always need monkeys ?
(In reply to comment #15) > Please translate "Er aiui" since I don't know any meaning for this and I can't > even guess ... $ emerge wtf; wtf aiui AIUI: as I understand it SCNR :P
(In reply to comment #6) > Waiting for a later-processed package in order to enable again a disabled > package tree seems tricky. I don't have any idea on how to do this in regard > to portage. It's not worth trying support something like that with the current dependency resolver. I'm working on a new resolver that will be able to handle things like this. If you want to see some more advanced resolver code that's available right now, have a look at pkgcore. I don't know if it's capable of doing what be want at the moment, but at least it's more advanced than portage's current resolver.
*** Bug 188620 has been marked as a duplicate of this bug. ***
*** Bug 189842 has been marked as a duplicate of this bug. ***
Er, update[1] now works round this bug (by basically doing what a human would do, ie scanning the list to see if the block is about to be cleared before the blocked package.) Otherwise it gives the option to Clean the blocker or skip the blocked package. I still think there's scope for automating some of the stuff users are advised to do, separately from the package manager; it's a lot easier to deal with knowing portage is doing the right thing. http://forums.gentoo.org/viewtopic-t-546828.html -- yes you can email me with bugs (NB it only ever runs emerge, so it's not doing anything you can't do manually [in terms of affecting installation])
This is fixed in 2.1.5_rc7. * Blockers are now resolved automatically in many more cases than before. When it's safe, blocked packages are uninstalled automatically so that users are no longer inconvenienced with the task. Automatically uninstalled packages are displayed in the merge list, marked "uninstall" and highlighted in red. With the --tree option enabled, it's possible to see which package(s) caused other ones to be automatically uninstalled.
(In reply to comment #21) > This is fixed in 2.1.5_rc7. Congratulations ! This is great news ! Thanks for the hard work; I understand this required quite some time for some of you guys.
*applauds* looks like portage has had a much-needed AI injection. It's currently helping me sort out a server that hasn't been updated in so long that I moved it from ~x86 to x86 and it still wants to update everything! amazing work guys, thanks :)
