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.
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 :/
That's why ebuilds are not supposed to use them ;).
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? :/
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.
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"
(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.
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 :)
This was discussed a couple of times already. When slots were introduced: https://bugs.gentoo.org/show_bug.cgi?id=338067#c22 https://bugs.gentoo.org/show_bug.cgi?id=338067#c26 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.
I personally use eselect since many years https://code.google.com/p/eselect-vala/source/browse/vala.eselect.m4 with a corresponding ebuild http://gpo.zugaina.org/app-admin/eselect-vala 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 /usr/bin/python ibqn@pls ~ $ which vala /usr/bin/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) Homepage: http://code.google.com/p/eselect-vala/ 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) Homepage: https://wiki.gnome.org/Vala 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) Homepage: https://wiki.gnome.org/Vala Description: Build infrastructure for packages that use Vala
Hi, 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: https://github.com/codito/gnome-shell-pomodoro/issues/169 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). thx
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.
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. Thanks.
No, Gentoo packages cannot rely on a random valac. Just like you do not rely on a random ruby or python.
https://bugs.gentoo.org/show_bug.cgi?id=580988 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
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.
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...
``` # Copyright 1999-2020 Gentoo Authors EAPI=4 DESCRIPTION="Eselect module to maintain vala compiler symlink" HOMEPAGE="http://code.google.com/p/eselect-vala/" SRC_URI="https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/eselect-vala/eselect-vala-0.1.2.tar.gz" LICENSE="GPL-2" SLOT="0" KEYWORDS="~amd64 ~x86" IUSE="" RDEPEND="app-admin/eselect dev-lang/vala" DEPEND="${RDEPEND} >=sys-devel/m4-1.4.13" DOCS="AUTHORS README" 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...
