| Summary: | dev-lang/vala:0.18 slot installs 0.17.5 and 0.17.6 versions | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markos Chandras (RETIRED) <hwoarang> |
| Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED INVALID | ||
| Severity: | QA | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
0.17.x versions are development versions that will lead to 0.18 stable versions, what I don't know is why some packages are using that strange way to get current vala compiler, does vala.eclass don't work for you? The problem is that the semantics are different in the 0.18 slow compared to the rest of the slots. Shouldn't that be renamed to 0.17 and then use 0.18 when this version is finally out? vala-0.17.x versions are betas for vala-0.18. The ebuild slots correspond to the suffixes upstream adds to executables and pkgconfig files: vala-0.17.6 installs /usr/bin/valac-0.18 and libvala-0.18.pc. Vala, like most packages in the gnome ecosystem, uses the traditional convention that odd minor versions are development, even are final release. The myvalavar/myvalac code that you proposed was therefore always broken - you just didn't notice until now because you don't use the gnome overlay, where unstable vala versions live until something in the tree needs them :) To automatically use the best installed vala slot, please use vala.eclass. |
Hi, I really don't understand why versions 0.17.X are in the 0.18 slot. This breaks all packages that use the following mechanism to get the currently installed vala compiler myvalaver="$(best_version dev-lang/vala | sed -e's@dev-lang/vala-\([0-9]*\.[0-9]*\)\..*@\1@g')" myvalac="$(type -p valac-${myvalaver})" So they match 0.17.X but what it is actually installed is vala-0.18 Is this expected?