[Aptitude-devel] Bug#890469: Bug#890469: aptitude: sometimes fails to resolve dependencies in a good way with '+' in the UI

Axel Beckert abe at debian.org
Thu Feb 15 00:48:46 UTC 2018


Control: tag -1 + confirmed

Vincent Lefevre wrote:
> The immediate solution should be to type '+' over "utils/main".
> But this yields:
> 
>   --\ utils          Various system utilities (5)
>     --\ main           The main Debian archive (5)                                      
> iuA stardict-common                    3.0.1-9.3                3.0.1-9.4               
> iB  stardict-gtk             -4096 B   3.0.1-9.3                3.0.1-9.4               
> iuA stardict-plugin          -8192 B   3.0.1-9.3                3.0.1-9.4               
> iuA stardict-plugin-espeak             3.0.1-9.3                3.0.1-9.4               
> iuA stardict-plugin-festival           3.0.1-9.3                3.0.1-9.4               
> 
> and for the broken stardict-gtk:
> 
> Some dependencies of stardict-gtk (broken, 3.0.1-9.3) are not satisfied:       ▒
>>   * stardict-gtk (upgrade, 3.0.1-9.3 -> 3.0.1-9.4) conflicts with              ▒
>     stardict-gnome                                                             ▒
>> The following packages conflict with stardict-gtk (broken, 3.0.1-9.3):         ▒
>>   * stardict-gnome (install, 3.0.1-9.4) conflicts with stardict-gtk            ▒
> 
> Note that stardict-gnome is not currently installed. The problem is
> that aptitude chooses to install it, hence the conflict. The same
> problem occurs when I hit '+' over "stardict-common". I suspect
> that aptitude tries to upgrade one package after the other, with a
> suboptimal resolution of OR'ed dependencies: stardict-com 3.0.1-9.4
> has:
> 
>   --\ Recommends (1)
>     --- stardict-gnome (>= 3.0.1-9.4) | stardict-gtk (>= 3.0.1-9.4)
> 
> So, when aptitude chooses to upgrade stardict-com, it wants
> to install stardict-gnome (not currently installed) instead
> of upgrading stardict-gtk.

Sounds familiar, yes. Happens occassionally, probably only if
versioned alternative dependencies in combination with conflicts are
involved. Which exists a bunch of times in Debian, but you probably
can count the cases on two hands.

(IMHO only a minor issue easy to workaround interactively, but I'll
leave it on normal and would like to hear Manuel's opinion on it.)

> This choice is surprising.

Not really. At that moment neither of the two alternative versioned
dependencies are fulfilled, hence it tries to fulfill the first
alternative dependency. The remainder seems to be a "local optimum"
issue it doesn't find to escape itself in time. It probably will find
the right solution later if you continue to request alternative
dependency solutions with ".".

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



More information about the Aptitude-devel mailing list