Federico Ferri wrote: > I can see also why portage is failing: > when (trying to) upgrading the first package, the whole package set > enters into a *transient* state, which is not valid for normal usage > (that is: one 0.14 lib, and all other 0.13 libs), but still has to be > valid in order for portage being able to upgrade correctly all the > packages, because when portage will end [successfully!], the system > will be again in a valid state.
It seems that the root of the problem is in the app-pda/synce-gnomevfs-0.13 dependencies. The =app-pda/synce-librapi2-0.13* atom is causing the conflict. You'll either need to adjust the dependencies of synce-gnomevfs-0.13 (if possible), or else get a new version that's compatible with synce-librapi2-0.14. > what I am going to propose here is a resolution strategy for this > (although this whole thing simply tells me that portage misses some > knowledge about the problem, like for example that dependencies should > be enforced only at transaction boundaries, or simply that we have a > class of dependencies that is irrelevant while system is in transient > state) > > but, without trying to introduce overcomplicated solutions, as an > user, I could solve the initial problem very easily: > resolution strategy for it is to unmerge the old synce-0.13 packages, > then the user will be able to install 0.14 packages. As said above, the problem is in the synce-gnomevfs-0.13 dependencies, and there's nothing portage can do to change that. > so, if the user can do it, why can't portage handle it? (so that even > a not-so-smart user could painlessly get out of this mess) FWIW, portage can resolve slot conflicts like this automatically, thanks to the patches from these two bugs: http://bugs.gentoo.org/show_bug.cgi?id=137562 http://bugs.gentoo.org/show_bug.cgi?id=275217 I plan to release this code in portage-2.1.6.14 in approximately 2 weeks. -- Thanks, Zac
