I see no special addition but a change that could break in hypothetical future prefix systems: diff -u /usr/portage/x11-misc/virtualgl/virtualgl-2.3.ebuild /usr/portage/local/layman/bumblebee/x11-misc/virtualgl/virtualgl-2.3-r1.ebuild --- /usr/portage/x11-misc/virtualgl/virtualgl-2.3.ebuild 2012-04-21 15:14:47.000000000 +0200 +++ /usr/portage/local/layman/bumblebee/x11-misc/virtualgl/virtualgl-2.3-r1.ebuild 2012-05-14 10:25:36.000000000 +0200 @@ -1,6 +1,6 @@ # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/x11-misc/virtualgl/virtualgl-2.3.ebuild,v 1.1 2012/04/21 13:14:47 pacho Exp $ +# $Header: $ EAPI="4" @@ -113,7 +113,7 @@ newconfd "${FILESDIR}/vgl.confd" vgl # Rename glxinfo to vglxinfo to avoid conflict with x11-apps/mesa-progs - mv "${ED}"/usr/bin/{,v}glxinfo || die + mv "${D}"/usr/bin/{,v}glxinfo } pkg_postinst() { I think you should simply drop it from overlay. Thanks :) Reproducible: Always
Fixed. https://github.com/Bumblebee-Project/bumblebee-gentoo/commit/f66b41f178739a903a48b0f0dff275df431ffe8b
@Pacho Hei! This is wrong. Your prefix support is already broken, so better not put it into ebuild at all, that is exactly what overlay ebuilds did and I told you that before. And your prefix support is broken, because you are not putting prefixes in all needed places, e.g., init script and install paths.
(In reply to comment #2) > @Pacho Hei! This is wrong. Your prefix support is already broken, so better > not put it into ebuild at all, that is exactly what overlay ebuilds did and > I told you that before. And your prefix support is broken, because you are > not putting prefixes in all needed places, e.g., init script and install > paths. Where do you think I should put prefixes also? I don't understand now :( Will also CC prefix team to try to clarify how to deal with this, I thought we should try to use "ED" instead of "D" in ebuilds with eapi4 (with the exception of emake install)
I cannot test this, but I think this is what's necessary at least: Index: virtualgl-2.3.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/x11-misc/virtualgl/virtualgl-2.3.ebuild,v retrieving revision 1.1 diff -u -r1.1 virtualgl-2.3.ebuild --- virtualgl-2.3.ebuild 21 Apr 2012 13:14:47 -0000 1.1 +++ virtualgl-2.3.ebuild 5 Jun 2012 10:37:41 -0000 @@ -33,7 +33,7 @@ src_prepare() { for file in rr/vglgenkey rr/vglrun rr/vglserver_config doc/index.html; do - sed -e "s#/etc/opt#/etc#g" -i ${file} || die + sed -e "s#/etc/opt#${EPREFIX}/etc#g" -i ${file} || die done default @@ -53,12 +53,12 @@ mycmakeargs=( $(cmake-utils_use ssl VGL_USESSL) - -DVGL_DOCDIR=/usr/share/doc/"${P}" - -DVGL_LIBDIR=/usr/$(get_libdir) - -DTJPEG_INCLUDE_DIR=/usr/include - -DTJPEG_LIBRARY=/usr/$(get_libdir)/libturbojpeg.so - -DCMAKE_LIBRARY_PATH=/usr/lib32 - -DVGL_FAKELIBDIR=/usr/fakelib/32 + -DVGL_DOCDIR="${EPREFIX}"/usr/share/doc/"${P}" + -DVGL_LIBDIR="${EPREFIX}"/usr/$(get_libdir) + -DTJPEG_INCLUDE_DIR="${EPREFIX}"/usr/include + -DTJPEG_LIBRARY="${EPREFIX}"/usr/$(get_libdir)/libturbojpeg.so + -DCMAKE_LIBRARY_PATH="${EPREFIX}"/usr/lib32 + -DVGL_FAKELIBDIR="${EPREFIX}"/usr/fakelib/32 ) cmake-utils_src_configure @@ -68,12 +68,12 @@ # Configure native version mycmakeargs=( $(cmake-utils_use ssl VGL_USESSL) - -DVGL_DOCDIR=/usr/share/doc/"${P}" - -DVGL_LIBDIR=/usr/$(get_libdir) - -DTJPEG_INCLUDE_DIR=/usr/include - -DTJPEG_LIBRARY=/usr/$(get_libdir)/libturbojpeg.so - -DCMAKE_LIBRARY_PATH=/usr/lib64 - -DVGL_FAKELIBDIR=/usr/fakelib/64 + -DVGL_DOCDIR="${EPREFIX}"/usr/share/doc/"${P}" + -DVGL_LIBDIR="${EPREFIX}"/usr/$(get_libdir) + -DTJPEG_INCLUDE_DIR="${EPREFIX}"/usr/include + -DTJPEG_LIBRARY="${EPREFIX}"/usr/$(get_libdir)/libturbojpeg.so + -DCMAKE_LIBRARY_PATH="${EPREFIX}"/usr/lib64 + -DVGL_FAKELIBDIR="${EPREFIX}"/usr/fakelib/64 ) cmake-utils_src_configure } @@ -117,5 +117,5 @@ } pkg_postinst() { - ewarn "You might need to adjust /etc/conf.d/vgl for your setup!" + ewarn "You might need to adjust ${EROOT}/etc/conf.d/vgl for your setup!" } cvs diff: Diffing files If you have any questions, shoot!
This is a start. Also init script should be changed to use prefix, but I'm not sure how well supported is openrc in prefix (if at all). It also would require testing that vgl run scripts can find all needed libs, there also might be some paths which need to be preffixed, e.g., VGL_BINDIR.
there is a GSoC project for the init scripts, but at the moment Prefix doesn't support them, in fact they are removed, so we can ignore them for the moment I checked some of the scripts, and indeed I think more is necessary to patch in Prefix paths.
You should just not even try to support prefix IF there are no prefix keywords in the ebuild. A common misconception is that if the ebuild is EAPI>=3 then you MUST add prefix offsets, and that is just false.
(In reply to comment #7) > You should just not even try to support prefix IF there are no prefix > keywords in the ebuild. A common misconception is that if the ebuild is > EAPI>=3 then you MUST add prefix offsets, and that is just false. That was exactly how I understood that. So if there is no ${ED} in the ebuild then there is no preffix support, but if you add that then you should support it properly. Question: Does portage automatically determines prefix support by the presence of prefix variables or it just assumes preffix support and let emerge fail?
(In reply to comment #8) > Question: Does portage automatically determines prefix support by the > presence of prefix variables or it just assumes preffix support and let > emerge fail? Support is determined by usage of Gentoo Prefix KEYWORDS. So, the latter of your two choices above.
(In reply to comment #7) > You should just not even try to support prefix IF there are no prefix > keywords in the ebuild. A common misconception is that if the ebuild is > EAPI>=3 then you MUST add prefix offsets, and that is just false. My idea was that, as "ED" will behave the same as "D", if I use it (even without prefix keywords), there is no lose at all and will simplify a bit the work if ebuild is ported to prefix in the future (In reply to comment #9) > (In reply to comment #8) > > > Question: Does portage automatically determines prefix support by the > > presence of prefix variables or it just assumes preffix support and let > > emerge fail? > > Support is determined by usage of Gentoo Prefix KEYWORDS. So, the latter of > your two choices above. Then, as it doesn't have prefix KEYWORDS, it won't break and either user "D" or "ED" would be allowed, no?
(In reply to comment #10) > Then, as it doesn't have prefix KEYWORDS, it won't break and either user "D" > or "ED" would be allowed, no? Sure, either is "allowed" but my personal preference is to NOT add stuff to ebuilds that isn't needed. I won't try to force my preferences on you.
OK, will leave it as is then, but will try to remember it for any other future ebuild to not make that conversion if not keyworded on prefix
I think it boils down to the following: If you can test an ebuild to be Prefix-correct (it is compiling and working as expected), please do make Prefix changes. If you can't, and hence you're not sure if your changes are all it takes, just don't make any. This way, the ebuild is consistent; it doesn't suggest to support Prefix, which is less confusing. I think this is what darkside is after. Either have it ok for Prefix, or not. Just a final word from my side on the issue: any actions to "support" Prefix, are much appreciated.
