Bug 249342 – sys-apps/portage-2.2_rc16 could have better USE dependency error messages

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description Mart Raudsepp 2008-11-30 03:31:23 UTC]

The messages portage gives for unsatisfies USE dependencies are quite confusing, as they seem to just say "no ebuilds to satisfy cat/pkg-ver[use-flag]" with not much explanation of what's that weird package name with the thing in brackets.

Furthermore it seems now the graph leading up to that is reported, but that isn't signified as such, instead it looks as if all the listed packages in the deptree require that, e.g:

emerge: there are no ebuilds to satisfy ">=dev-java/antlr-2.7.1[java]".
(dependency required by "dev-java/gjdoc-0.7.9" [installed])
(dependency required by "net-dns/libidn-1.9-r1" [ebuild])
(dependency required by "kde-base/kdelibs-3.5.10-r2" [ebuild])
(dependency required by "kde-misc/kdnssd-avahi-0.1.2-r1" [ebuild])

... only gjdoc really needs it (while the messages claim all of them do). Also in the above example, it would be nice to tell that it is only required if net-dns/libidn-1.9-r1 has USE=java, so the user would be easily able to see what feature he would need to sacrifice in a higher level package to avoid the reported failure instead of providing what it needs, so that the user can easily make a more informed decision on if she wants to disable that USE=java from libidn or add USE=java to antlr.

And now the weirdest part of this example:

emerge: there are no ebuilds to satisfy ">=dev-java/antlr-2.7.1[java]" is not really true. The ebuild in my portage tree very well has IUSE=java on dev-java/antlr-2.7.1, but the version that was installed (the ebuild in /var/db/pkg) doesn't, because it was IUSE=nojava before, and now it's IUSE=+java, but portage is telling me there is no ebuilds to satisfy antlr[java], while in reality all I need to do is re-emerge antlr (and perhaps in this case it is fine to do it automatically?)

[Comment 1 Mart Raudsepp 2008-11-30 03:32:48 UTC]

I also have the following on top of the already pasted bits of emerge output, which could probably shed some light into the last case of antlr IUSE nojava vs +java:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-java/antlr:0

  ('ebuild', '/', 'dev-java/antlr-2.7.7', 'merge') pulled in by
    ('installed', '/', 'dev-java/gjdoc-0.7.9', 'nomerge')

  ('installed', '/', 'dev-java/antlr-2.7.7', 'nomerge') pulled in by
    @world


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man page
or refer to the Gentoo Handbook.

[Comment 2 Zac Medico 2008-11-30 04:36:41 UTC]

You need use --newuse or explicitly add dev-java/antlr to the command line so that it will be reinstalled.

(In reply to comment #0)
> emerge: there are no ebuilds to satisfy ">=dev-java/antlr-2.7.1[java]".
> (dependency required by "dev-java/gjdoc-0.7.9" [installed])
> (dependency required by "net-dns/libidn-1.9-r1" [ebuild])
> (dependency required by "kde-base/kdelibs-3.5.10-r2" [ebuild])
> (dependency required by "kde-misc/kdnssd-avahi-0.1.2-r1" [ebuild])
> 
> ... only gjdoc really needs it (while the messages claim all of them do). 

Well, it's not intended to claim that all of them do. It's supposed to be the chain of dependencies that pulled it in: gjdoc requires antlr, libidn requires gjdoc and so on.

> antlr[java], while in reality all I need to do is re-emerge antlr (and perhaps
> in this case it is fine to do it automatically?)

Yes, future versions will do it automatically but for now you have to specify --newuse or add dev-java/antlr to the command line.

*** This bug has been marked as a duplicate of bug 249185 ***