Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 513658 - dev-lang/vala: please use alternatives.eclass or eselect
Summary: dev-lang/vala: please use alternatives.eclass or eselect
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement with 5 votes (vote)
Assignee: Gentoo Linux Gnome Desktop Team
Depends on:
Reported: 2014-06-18 07:26 UTC by Michał Górny
Modified: 2021-07-27 04:59 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-06-18 07:26:30 UTC
AFAICS we currently only install versioned vala. While it's indeed fun and etc., and it's easy hacked around via vala.eclass, it makes local development PITA.

For example, I'm trying to work on a solution for bug #513652, and I had to reproduce most of what vala.eclass does (including local pkg-config files) just to make configure find vala...

Please use either alternatives.eclass or eselect to provide proper, non-versioned vala symlinks for out-of-ebuild use.
Comment 1 Pacho Ramos gentoo-dev 2014-06-18 08:58:34 UTC
But providing unversioned symlinks will cause issues as not all tools are compatible with latest vala always and, if the administrator switches the symlink, the app would start to fail :/
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-06-18 14:13:43 UTC
That's why ebuilds are not supposed to use them ;).
Comment 3 Pacho Ramos gentoo-dev 2014-06-18 16:35:36 UTC
But, if the unversioned valac is not wanted to be used by other packages... why not leave it to each admin to manually symlink it to the version he/she wants to use? :/
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-06-18 16:49:42 UTC
Because we're supposed to provide useful environment. Expecting each admin to fix your fault is not a good thing to do. Especially that it's *my* time wasted on figuring out what Gentoo does wrong and how to fix it properly, so that I can at least start working on fixing the actual issue.
Comment 5 Pacho Ramos gentoo-dev 2014-06-18 16:58:28 UTC
Well, will wait for other team opinions then. From my point of view, if we finally provide an unversioned valac link, I would opt for alternatives.eclass "way"
Comment 6 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-06-18 17:20:26 UTC
(In reply to Pacho Ramos from comment #5)
> Well, will wait for other team opinions then. From my point of view, if we
> finally provide an unversioned valac link, I would opt for
> alternatives.eclass "way"

My vote is for eselect. Just like some ebuilds have to set VALA_MAX_API_VERSION because newer vala breaks them, so people developing with vala in their home directory need a specific vala version, not the latest one.

I had wanted to add this eselect module for a long time, but never got around to it.
Comment 7 Pacho Ramos gentoo-dev 2014-06-18 17:45:43 UTC
Taking care we are the only distro supplying old vala versions, I wondered if people would like to develop for old versions :|

But do what you prefer, you will know what is the best option as I am not a vala developer at all :)
Comment 8 Gilles Dartiguelongue (RETIRED) gentoo-dev 2014-06-21 09:38:22 UTC
This was discussed a couple of times already.

When slots were introduced:

Unversioned binaries, for whatever reason you need them, will be a problem for package maintainers. It will hide the dependency of packages that lookup the unversioned binaries for some reason and triggers automatic rebuilds if it is found, dependency or specific revision may go unoticed.

I know this is annoying for devs but using alternatives has already been tried, check ebuild history and using eselect is just another way to do the same thing.

Imho the balance is this:
* normal users don't care, they want their stuff to build, always
* maintainers care, they want to know what is needed to build their stuff, they can use eclass to get it straight
* developers care, they want to know what is needed to build their stuff but they want it simple, use m4_foreach just like for other libs that have several slots available which are mostly compatible for the use being done (tracker, libgda, etc) or a script to set path when starting working on a project.
Comment 9 Evgeny Bobkin 2014-06-21 15:29:34 UTC
I personally use eselect since many years with a corresponding ebuild

to develop with vala, but the selected vala symlink should not have any impact on ebuilds.

So I prefer the same treatment as for python:
ibqn@pls ~ $ which python
ibqn@pls ~ $ which vala

However in theory ebuilds should not rely on /usr/bin/vala symlink, and must pick the version according to the settings in the ebuild.

ibqn@pls ~ $ ls -l $(which vala)
lrwxrwxrwx 1 root root 18 Dec 11  2013 /usr/bin/vala -> /usr/bin/vala-0.22
ibqn@pls ~ $ eix -I vala
[I] app-admin/eselect-vala [2]
     Available versions:  (~)0.1.2 **9999
     Installed versions:  0.1.2[?](09:20:25 AM 06/06/2013)
     Description:         Eselect module to maintain vala compiler symlink

[I] dev-lang/vala
     Available versions:  
     (0.18) 0.18.1
     (0.20) 0.20.1
     (0.22) 0.22.1
     (0.24) (~)0.24.0 (~)0.24.0[1] (~)0.24.0-r1
       {test +vapigen}
     Installed versions:  0.20.1(0.20)(11:36:47 AM 09/01/2013)(vapigen -test) 0.22.1(0.22)(09:30:39 AM 11/15/2013)(vapigen -test) 0.24.0-r1(0.24)(09:21:57 PM 05/27/2014)(vapigen -test)
     Description:         Compiler for the GObject type system

[I] dev-libs/vala-common
     Available versions:  0.22.1 (~)0.24.0 (~)0.24.0[1]
     Installed versions:  0.24.0[1](11:34:48 AM 04/21/2014)
     Description:         Build infrastructure for packages that use Vala
Comment 10 Grégory Salvan 2015-01-22 23:04:11 UTC
As a simple user, I had problems to install pomodoro gnome (3.14) shell extension due to vala concurrent versions.

I opened a bug for the pomodoro extension, but it seems more due to gentoo.
I'm linking the bug here in case:

I've fixed the problem locally, but I'm open for recommendations, I don't like the final solution (see replacement for part 2 in comments).

Comment 11 Gilles Dartiguelongue (RETIRED) gentoo-dev 2015-10-25 10:37:31 UTC
I have thought about this again recently and I was wondering if it would be an acceptable solution to provide an eselect-vala plugins that install a script that gives users what they want but dies when called from portage. This way we avoid our fellow developers failing to use the eclass/set needed env variables and users get the ease of use they want.
Comment 12 jorgicio 2015-12-30 19:32:03 UTC
It happened to me. Some packages are build to find valac only and not by an specific version. I think eselect-vala is needed.

Also, there's the vala overlay, and tried eselect-vala and working. eselect-vala must be as an official package and not in an overlay.

Comment 13 Gilles Dartiguelongue (RETIRED) gentoo-dev 2015-12-30 23:04:33 UTC
No, Gentoo packages cannot rely on a random valac. Just like you do not rely on a random ruby or python.
Comment 14 jospezial 2016-04-29 00:55:08 UTC

There you can see dev-libs/libappindicator from the portage tree that does not compile vala vapi bindings when it does not find unversioned /usr/bin/vapigen
Comment 15 Dylan 2020-05-29 21:44:47 UTC
meson developer here. This is a real pain for us, as we expect (and other distros provide) a plain, unversioned, `valac`, `vapigen`, etc. It would be fantastic to have an eselect-vala so that people who want to build something don't have to go figure out why things just work in debian, fedora, and arch, but don't work on gentoo.
Comment 16 Szymon Scholz 2020-06-26 10:45:37 UTC
I dunno why Vala does not have the same eselect mechanism as Python, Java, Scala, Ruby, even GCC. When you use python 3.7, but compile packages with support for python 3.{6,7,8} are you relying on random version? Latest stable or required(<=valac-1.23), or specified via variable should be used for compilation.

Now i (and other people) must deal with overlays... It's the first time something does not work in Gentoo out of the box and that's not because i failed somewhere. 

We have great tool called eselect, why not just make use of it? 

Gentoo Community members are great people, i think this issue can be resolved without dispute about how. I'll ofc install eselect-vala, not official...
Comment 17 David Heidelberg (okias) 2020-08-28 08:13:04 UTC
# Copyright 1999-2020 Gentoo Authors


DESCRIPTION="Eselect module to maintain vala compiler symlink"


KEYWORDS="~amd64 ~x86"



src_install() {
	emake DESTDIR="${D}" install
	dodoc ${DOCS}
updated app-admin/eselect-vala/eselect-vala-0.1.2.ebuild due to G Code is now archive...