1 |
On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: |
2 |
> Hi folks, |
3 |
> |
4 |
> I've been told that my use of eblits in dev-lang/php is something I |
5 |
> should get rid of as soon as possible. Suggested alternative by ferring: |
6 |
> use elibs. |
7 |
> |
8 |
> So here goes: I want to see GLEP33[1] implemented in portage, so I can |
9 |
> shift the eblits core and currently global functions into elibs and |
10 |
> probably push the eblits I use for php into the same structure. |
11 |
> |
12 |
> Basic question: what needs to be done to get this GLEP accepted and |
13 |
> implemented (it's current status is moribound)? |
14 |
> |
15 |
> I extracted a list of things we (or rather the portage and all other PM |
16 |
> teams) need to do: |
17 |
> |
18 |
> (1) create elibs() function to enable importing elibs |
19 |
|
20 |
There's a caveat here; imagine one of the current PM's processing an |
21 |
EAPI=4 (or whatever) ebuild that uses elib- specifically there will be |
22 |
a global scope function invocation of a function that doesn't exist. |
23 |
|
24 |
In the past, a minority of folk have raised complaints about this- it |
25 |
was never stated as best I know, but my assumption looking back is |
26 |
that it was due primarily to paludis getting pissy about ebuilds |
27 |
outputing anything during metadata sourcing (paludis at this point |
28 |
isn't pissy about it- mainly sinc eclasses can invoke die after all). |
29 |
|
30 |
Managers should implementat that functionality; orthogonal to it, |
31 |
we've got a few options for how to deal with an EAPI=4 ebuild being |
32 |
metadata sourced by a <=EAPI3 PM (meaning, there will be a "command |
33 |
not found" spat to stderr during sourcing): |
34 |
|
35 |
1) if 'elib' isn't defined, define it as a no-op w/in a |
36 |
profile.bashrc. This doesn't work for paludis (they don't do profile |
37 |
bashrc at all), but works for pkgcore/portage- would silence the |
38 |
output in the majority basically. This address gentoo-x86, but |
39 |
cleanly for stand alone repositories. |
40 |
|
41 |
2) variation of #1, require consuming ebuilds to inherit an eclass |
42 |
that has the fallback no-op in it, rather than profile. This would |
43 |
work for paludis, although again, it's gentoo-x86 specific and would |
44 |
be limited to overlays. All standalone tree's would have to bundle |
45 |
their own eclass w/ the no-op. |
46 |
|
47 |
3) glep55; note that I'm purely listing out options here, will leave |
48 |
the people pushing that glep to advocate it. |
49 |
|
50 |
4) I should've thought of this a few years back, but frankly another |
51 |
option is to fix the @!#*ing package managers. They should collect |
52 |
stdout/stderr output during sourcing, but only output it if the |
53 |
metadata sourcing resulted in an EAPI the PM supported. If it's an |
54 |
EAPI the PM doesn't support, it wouldn't know how to write the cache |
55 |
for the ebuild anyways. |
56 |
|
57 |
5) ignore that their may be output, and get on with our lives and |
58 |
implementing features. |
59 |
|
60 |
From where I'm sitting, #4 should be implemented regardless of what |
61 |
solution is choosen. Personally, I prefer #1, but #2 is easy enough |
62 |
to jam in if people really are bother by a couple of overlays making |
63 |
noise for people running a stale package manager. |
64 |
|
65 |
|
66 |
Either way, this particular naggle needs a decision. |
67 |
|
68 |
|
69 |
> (2) extend repoman to handle new style elibs and eclass signing/checking |
70 |
> (3) profit ;) |
71 |
|
72 |
I'd suggest breaking this up- specifically try to get elibs in, but do |
73 |
not bind their timelines/existance to eclass refactoring. |
74 |
|
75 |
|
76 |
> Also, there're some question I have: |
77 |
> (1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of |
78 |
> "Cases where the constant [metadata] requirement is violated are known" |
79 |
> - who exactly are the current offenders? |
80 |
|
81 |
Talk to vapier- he had some abuses of SLOT rewriting during merging |
82 |
(nasty hack that only works for portage) last time I knew. Php had |
83 |
something similar at the time this glep was written, although that's |
84 |
since been removed. |
85 |
|
86 |
|
87 |
> (2) What's the dev community feeling on "The end of backwards |
88 |
> compatibility..." section in the GLEP? Personal opinion: when the |
89 |
> council reached consensus that old eclasses can be removed with due |
90 |
> last-rites, this section became obsolete. Just putting new-style |
91 |
> eclasses in their own dirs in eclass/ might again be an option. Please |
92 |
> discuss. |
93 |
|
94 |
The env saving part of that section is no longer relevant, and the |
95 |
question of how long to keep eclasses around was addressed in the last |
96 |
council meeting: |
97 |
http://www.gentoo.org/proj/en/council/meeting-logs/20100726-summary.txt |
98 |
|
99 |
Now, if eclasses2 went forward, how long to keep the old eclass |
100 |
directory around is a seperate question. |
101 |
|
102 |
|
103 |
> Instead of all the backwards-compatibility issues the GLEP deals with, |
104 |
> we could just sneak the implementation into EAPI4 and be done with it. |
105 |
|
106 |
Exempting tweaking the inherit mechanism to use a new eclass location, |
107 |
a lot of the env saving bits of that glep are no longer relevant. |
108 |
|
109 |
My suggestion? Split this into two, elibs, and eclass refactoring. |
110 |
~brian |