1 |
On 05/29/2016 04:25, Ulrich Mueller wrote: |
2 |
>>>>>> On Sun, 29 May 2016, Rich Freeman wrote: |
3 |
> |
4 |
>> What I would love to see is this be standardized. An eclass or a |
5 |
>> GLEP seems like the logical approach. |
6 |
> |
7 |
> I am strongly opposed against this. Ebuilds should not source |
8 |
> executable code from random locations. This is also a huge QA |
9 |
> violation, since PMS neither guarantees FILESDIR to be available in |
10 |
> global scope (so especially, not during metadata generation), nor in |
11 |
> any of the pkg_* phases (like pkg_setup, where mips-sources sources |
12 |
> its eblits). |
13 |
|
14 |
I believe this was addressed already back in 2010, for mips-sources at least. |
15 |
Can't speak for the other eblit consumers. See Bug #300370. |
16 |
|
17 |
Eblits used to be loaded in global scope, which is what caused the $FILESDIR |
18 |
issue, so the change was to move them into a function, then call that function |
19 |
from pkg_setup. This also makes sure the eblit code gets packed into the tbz2 |
20 |
so it's available when $FILESDIR isn't. |
21 |
|
22 |
As for sourcing from random locations...point, because the standard path isn't |
23 |
set in stone in an eclass or GLEP. $FILESDIR/eblits is the path used by at |
24 |
least glibc and mips-sources eblits. I haven't looked at Perl or PHP's. |
25 |
Totally open to addressing that in a sane manner. |
26 |
|
27 |
|
28 |
> If there really is a need for such a feature, we should rather follow |
29 |
> an approach like the per-package eclasses previously suggested by mabi |
30 |
> and antarus [1], and support a pkg-inherit function in the next EAPI. |
31 |
> (Though I wouldn't add a new function, but add an option to inherit, |
32 |
> like "inherit -p".) |
33 |
|
34 |
That seems like an attempt to revive the elibs idea, which is what eblits were |
35 |
eventually supposed to morph into at some point. I have no idea why elibs died |
36 |
off. Probably lack of interest or need back in 2005, when Gentoo was far, far |
37 |
smaller in size and scope. |
38 |
|
39 |
IMHO, to avoid that happening again, any such solution (regardless of name) |
40 |
should probably look at implementing the bare minimum needed to replace all |
41 |
existing consumers of eblits with the least amount of upheaval. Then new |
42 |
functionality can be added down the road. Try to do everything at once, and |
43 |
it'll just die off again. |
44 |
|
45 |
|
46 |
> We could even think about per-category eclasses ("inherit -c"), |
47 |
> although it is not obvious where one would store them. |
48 |
|
49 |
Easy...under eclass/, in per-category sub-folders :) |
50 |
|
51 |
(yay for more directory bureaucracy!) |
52 |
|
53 |
|
54 |
> Ulrich |
55 |
> |
56 |
> [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?view=markup |
57 |
> |
58 |
|
59 |
|
60 |
-- |
61 |
Joshua Kinard |
62 |
Gentoo/MIPS |
63 |
kumba@g.o |
64 |
6144R/F5C6C943 2015-04-27 |
65 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
66 |
|
67 |
"The past tempts us, the present confuses us, the future frightens us. And our |
68 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
69 |
|
70 |
--Emperor Turhan, Centauri Republic |