Re: [gentoo-dev] portage and conflict resolutions!? (really is about =cat/pkg-${VER}* dependencies)

[Zac Medico]

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