sci-libs/gsl should be multilib-aware Reproducible: Always
Created attachment 388828 [details, diff] sci-libs/gsl-1.16 multilib patch
(In reply to Igor Ulyanov from comment #0) > sci-libs/gsl should be multilib-aware Why? sci-libs/gsl is not really a base library.
And it might the easiest to create a pull request on github: <https://github.com/gentoo-science/sci/pulls>
(In reply to Christoph Junghans from comment #2) > (In reply to Igor Ulyanov from comment #0) > > sci-libs/gsl should be multilib-aware > Why? sci-libs/gsl is not really a base library. Is there any policy for multilib-awareness? > And it might the easiest to create a pull request on github: > <https://github.com/gentoo-science/sci/pulls> What is the status of gentoo-science overlay against portage? Is there any reason to fill request in this overlay if i've added patched ebuild to my own overlay displacer already?
(In reply to Igor Ulyanov from comment #4) > (In reply to Christoph Junghans from comment #2) > > (In reply to Igor Ulyanov from comment #0) > > > sci-libs/gsl should be multilib-aware > > Why? sci-libs/gsl is not really a base library. > Is there any policy for multilib-awareness? "To make it more precise, that is the goal of gx86-multilib project: to provide multilib libraries whenever they are necessary to run some stuff that can't be run in native ABI." (bug #474910#c6) So where would we need a 32bit libgsl? > > And it might the easiest to create a pull request on github: > > <https://github.com/gentoo-science/sci/pulls> > What is the status of gentoo-science overlay against portage? Is there any > reason to fill request in this overlay if i've added patched ebuild to my > own overlay displacer already? sci-libs/gsl is maintained by the science herd and the gentoo-science is their official overlay. It can be seen as a staging area to the portage tree. Also your diff is against 1.16-r1, which is part of the gentoo-science overlay. Also, in your patch dependencies (virtual/cblas) have not been updated.
(In reply to Christoph Junghans from comment #5) > So where would we need a 32bit libgsl? It is needed for me personnaly for out of portage applications development. > Also your diff is against 1.16-r1 It seems I have to apologize, ive renamed ebuild from portage to r1 before making changes... > Also, in your patch dependencies (virtual/cblas) have not been updated. It is probably not perfect but at least works for me (resolving virtual/cblas dependencies seems difficult to me with my poor portage knowledge). No problem to resolve this as WONTFIX ot smth similar. Thanks for reply.
As sci-libs/xblas and sci-libs/cblas-reference are multlib already, let's convert gsl, too. Just do a pull request, we can take it from there.
Done it in science overlay: +*gsl-1.16-r2 (10 Nov 2014) + + 10 Nov 2014; Christoph Junghans <ottxor@gentoo.org> +gsl-1.16-r2.ebuild: + added multilib support (bug #528622) + +*cblas-2.0-r3 (10 Nov 2014) + + 10 Nov 2014; Christoph Junghans <ottxor@gentoo.org> +cblas-2.0-r3.ebuild: + added multilib support (bug #528622) +
