Summary: | <dev-lang/vala-0.20.0 is blocking dev-libs/gobject-introspection-1.36.0 and portage doesn't resolve the block | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tman <cornicx> |
Component: | [OLD] GNOME | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | droshalla, esigra, gnome, nbowler, stefantalpalaru |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=264434 https://bugs.gentoo.org/show_bug.cgi?id=525052 https://bugs.gentoo.org/show_bug.cgi?id=706278 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 300071, 389719, 472632, 480736 |
Description
tman
2013-07-26 00:37:17 UTC
I'm getting the same thing on ~amd64 without the gnome overlay. The workaround is to "emerge -1 vala" in order to install the "0.20" slot. After that, the block disappears. (In reply to Stefan Talpalaru from comment #1) > I'm getting the same thing on ~amd64 without the gnome overlay. The > workaround is to "emerge -1 vala" in order to install the "0.20" slot. After > that, the block disappears. I was having the same problem and this worked for me. (In reply to Stefan Talpalaru from comment #1) > I'm getting the same thing on ~amd64 without the gnome overlay. The > workaround is to "emerge -1 vala" in order to install the "0.20" slot. After > that, the block disappears. CCing portage team as I don't know why it's unable to try to update vala to resolve the blockers (In reply to Pacho Ramos from comment #3) > CCing portage team as I don't know why it's unable to try to update vala to > resolve the blockers It can't because of all these deps on the dev-lang/vala:0.18 slot, shown in comment #0: (dev-lang/vala-0.18.1::gentoo, installed) pulled in by dev-lang/vala:0.18[vapigen] required by (net-libs/telepathy-glib-0.20.3::gentoo, installed) dev-lang/vala:0.18[vapigen] required by (net-libs/gssdp-0.14.3::gentoo, installed) dev-lang/vala:0.18[vapigen] required by (dev-libs/libindicate-12.10.1::gentoo, installed) dev-lang/vala:0.18[vapigen] required by (net-libs/gupnp-0.20.3::gentoo, installed) dev-lang/vala:0.18 required by (dev-util/geany-plugins-1.23::lokal, installed) dev-lang/vala:0.18[vapigen] required by (dev-libs/libdbusmenu-0.6.2::gentoo, installed) But all of them are using vala.eclass, letting them to use slots equal or newer than 0.18. Maybe it's because of the way vala.eclass handles this :/ One way to handle this better could be to add a "vala" USE flag to gnome-core-libs pulling in vala:0.20 With deps like || ( dev-lang/vala:0.20[ dev-lang/vala:0.18 ), if some other package has a hard dep on vala:0.18, it will cause other packages to also pull in vala:0.18 instead of vala:0.20. For example, the whole problem could be due to bad dependencies of that dev-util/geany-plugins-1.23::lokal from the lokal overlay. You can check the deps like this: portageq metadata / ebuild ev-util/geany-plugins-1.23::lokal DEPEND RDEPEND I'm having the same problem locally, and all of the packages appear to have the || ( dev-lang/vala:0.20 dev-lang/vala:0.18 ) deps. It's like a new case of bug 264434. Workaround: emerge --unmerge dev-lang/vala:0.18 Or install :0.20 slot, no? Or does it have any problem? (In reply to Pacho Ramos from comment #10) > Or install :0.20 slot, no? Or does it have any problem? Yeah, that will probably work. The reason for this bug is that portage's || dependency evaluation logic organizes atom choices into bins, and the dev-lang/vala:0.18 atom choice go into a preferred bin when vala:0.18 is installed, even though the dev-lang/vala:0.20 choice represents an available upgrade. In order to solve this problem, it seems like the logic needs to account for options such as --deep and --update, and use them to decide whether or not it would be appropriate to treat vala:0.20 as the preferred choice. This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=94130821ab21186aeca7c514236a60acf6a71082 This is fixed in 2.1.13.2 and 2.2.0_alpha191. |