Bug 520950 – dev-java/icedtea-web-1.3.2-r7 ebuild incorrectly treated as masked and with no reason of masking

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Arfrever Frehtes Taifersar Arahesis 2014-08-26 09:13:09 UTC]

After installing dev-java/icedtea-7.2.4.7 with fix for dependencies (bug #500264) and next switching to a copy of repository without this fix, when performing testing for bug #515230, I reproduced this bug in Portage:

$ ABI_X86="32 64" emerge -ptv --backtrack=1000000 app-emulation/wine sys-devel/gcc:{4.7,4.8}
...

!!! All ebuilds that could satisfy "dev-java/icedtea-web:7[nsplugin]" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-java/icedtea-web-1.3.2-r7::gentoo (masked by: )

(dependency required by "dev-java/icedtea-7.2.4.7::gentoo[nsplugin]" [installed])
(dependency required by "virtual/jdk-1.7.0::gentoo" [installed])
(dependency required by "media-libs/libjpeg-turbo-1.3.1::gentoo" [ebuild])
(dependency required by "virtual/jpeg-0-r2::gentoo" [ebuild])
(dependency required by "media-libs/lcms-2.6::gentoo[jpeg]" [ebuild])
(dependency required by "app-emulation/wine-1.7.21::gentoo[abi_x86_32,lcms]" [ebuild])
(dependency required by "app-emulation/wine" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

$ emerge -Opv dev-java/icedtea dev-java/icedtea-web

These are the packages that would be merged, in order:

[ebuild   R    ] dev-java/icedtea-7.2.4.7:7::gentoo  USE="X alsa cups javascript jbootstrap nsplugin nss source webstart -cacao -cjk -debug -doc -examples -jamvm -kerberos -pax_kernel -pulseaudio -selinux% {-test} -zero" ELIBC="(-FreeBSD)" 0 KiB
[ebuild   R    ] dev-java/icedtea-web-1.4.2-r1::gentoo  USE="icedtea7 javascript nsplugin -doc {-test}" ELIBC="(-FreeBSD)" 0 KiB

Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB

[Comment 1 Zac Medico 2014-08-28 10:13:04 UTC]

I've reproduced this bug using a copy of Arfrever's configuration, and with pdb I got this backtrace which shows the cause:

-> self.altlist()
  pym/_emerge/depgraph.py(6267)altlist()
-> self._resolve_conflicts()
  pym/_emerge/depgraph.py(6394)_resolve_conflicts()
-> self._process_slot_conflicts()
  pym/_emerge/depgraph.py(1241)_process_slot_conflicts()
-> self._solve_non_slot_operator_slot_conflicts()
  pym/_emerge/depgraph.py(1208)_solve_non_slot_operator_slot_conflicts()
-> self._create_graph()
  pym/_emerge/depgraph.py(2031)_create_graph()
-> allow_unsatisfied=allow_unsatisfied):
  pym/_emerge/depgraph.py(2639)_add_pkg_deps()
-> allow_unsatisfied):
  pym/_emerge/depgraph.py(2655)_add_pkg_dep_string()
-> allow_unsatisfied)
  pym/_emerge/depgraph.py(2804)_wrapped_add_pkg_dep_string()
-> allow_unsatisfied=allow_unsatisfied):
> pym/_emerge/depgraph.py(2143)_add_dep()
-> self._dynamic_config._unsatisfied_deps_for_display.append(

This shows that _solve_non_slot_operator_slot_conflicts calls _create_graph with allow_unsatisfied = True, resulting in an unsatisfied dependency message.  The _create_graph method is actually intended to called with allow_unsatisfied = False when completing the graph (without --deep), since the user has not explicitly requested traversal of deep dependencies. So, I would suggest to suppress the unsatisfied dependency message unless the relevant packages have been pulled into the graph by user arguments (such as --deep @world).

[Comment 2 Zac Medico 2014-09-02 18:00:13 UTC]

Created attachment 384126 [details, diff]
depgraph._add_dep: fix bug #520950

This handles a case which occurs when _solve_non_slot_operator_slot_conflicts calls _create_graph. In this case, ignore unsatisfied deps for installed packages only if their depth is beyond the depth requested by the user and the dep was initially unsatisfied (not broken by a slot conflict in the current graph).

[Comment 3 Zac Medico 2014-09-02 22:56:11 UTC]

Created attachment 384138 [details, diff]
depgraph._add_dep: fix bug #520950

This updated patch has some corrections in the depth logic.

[Comment 4 Zac Medico 2014-09-02 23:34:41 UTC]

Created attachment 384140 [details, diff]
depgraph._add_dep: fix bug #520950

This updated patch has some logic to avoid possible misbehavior for removal actions.

[Comment 5 Zac Medico 2014-09-03 16:45:33 UTC]

Created attachment 384162 [details, diff]
depgraph._add_dep: fix bug #520950

This version of the patch omits code for removal actions, and adds an additional comment about removal actions.

[Comment 6 Zac Medico 2014-09-03 16:55:12 UTC]

Created attachment 384164 [details, diff]
depgraph._add_dep: fix bug #520950

Fix syntax error in previous attachment.

[Comment 7 Zac Medico 2014-09-03 23:55:57 UTC]

Created attachment 384180 [details, diff]
depgraph._add_dep: fix bug #520950

This patch adds logic to account for the fact that depth is meaningless for packages that are not reachable as deep dependencies of arguments.

[Comment 8 Zac Medico 2014-09-04 17:08:31 UTC]

Created attachment 384202 [details, diff]
depgraph._add_dep: fix bug #520950

This patch fixes _expand_set_args to consistently preserve any SetArg nodes (and their reset_depth attributes) that are already in the graph.  I'm fairly confident that everything is accounted for now, so I do not anticipate any more updates to this patch unless somebody else finds a problem.

[Comment 9 Zac Medico 2014-09-06 23:49:35 UTC]

Created attachment 384316 [details, diff]
depgraph._add_dep: fix bug #520950

This patch adds a test case which reproduces the bug, and also introduces a _UNREACHABLE_DEPTH constant to fix broken/confusing logic resulting from insinstance(True, int) returning true.

[Comment 10 Zac Medico 2014-09-06 23:51:47 UTC]

Created attachment 384318 [details, diff]
depgraph._add_dep: fix bug #520950

The last attachment was incorrect. Here is the correct one.

[Comment 11 Zac Medico 2014-09-07 04:22:50 UTC]

I'll be maintaining the patch in this branch on github:

  https://github.com/zmedico/portage/tree/bug_520950

Now it has some test cases that aren't included in the attached patch.

[Comment 12 Zac Medico 2014-09-11 21:54:42 UTC]

Following approval in today's meeting, I've pushed this fix to master, for release in portage-2.2.13:

https://github.com/gentoo/portage/commit/336ab90212c80ce9548362bf4fbdafd388c3515c

[Comment 13 Zac Medico 2014-09-17 17:42:52 UTC]

This is fixed in 2.2.13.