Gentoo Archives: gentoo-science

From: "Sébastien Fabbro" <bicatali@g.o>
To: gentoo-science@l.g.o
Subject: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates
Date: Tue, 21 Jan 2014 17:05:05
In Reply to: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates by Reinis Danne
1 On Mon, Jan 20, 2014 at 9:53 AM, Reinis Danne <rei4dan@×××××.com> wrote:
3 >
4 > I have cleaned up a bit alternatives-2.eclass to make it easier to review.
5 > Also if someone knows any shortcommings of this eclass as it is, then point
6 > it out, I'll try to address them.
7 >
8 > I hope this can be soon moved to the main tree thus closing the divide
9 > between
10 > science overlay and portage tree.
11 >
14 Your changes are mostly minor and only apply to the eclass, so I have no
15 comments. You should commit them to the overlay, code reviews on the github
16 review panel are more practical than on the mailing list.
17 One important thing the creation of eselect modules could be done directly
18 from eselect rather than the eclass, keeping the eclass much more simple,
19 and allowing users to create their own providers easily. I may work on it.
20 I had some local changes of eselect and I added the repo [1] to the github
21 gentoo-science, that you can test by unmasking eselect-9999.
23 Known issues of the alternatives framework:
24 * when having more than 1 provider, updating a package that provided the
25 eselected provider, will not re-eselect the same provider unless it was the
26 first on the list
27 * possible residual orphan files
28 * given the number of bugs, we should keep the linking to the reference
29 names libraries, so we could eselect providers without re-compiling all
30 reverse dependencies. We could do this in the open sourced providers by
31 changing the soname of the libraries we compile, and in the binary ones
32 (mkl,amcl...) with a link script generated library.
35 [1]
37 Sebastien