1 |
On 2 August 2010 12:11, Brian Harring <ferringb@×××××.com> wrote: |
2 |
> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: |
3 |
>> Hi folks, |
4 |
>> |
5 |
>> I've been told that my use of eblits in dev-lang/php is something I |
6 |
>> should get rid of as soon as possible. Suggested alternative by ferring: |
7 |
>> use elibs. |
8 |
|
9 |
There's a couple of hundred lines of repeated metadata between |
10 |
php-5.3.2 and php-5.3.3 - not identical, but similar enough that there |
11 |
would be gains from factoring it out, and elibs won't help with that. |
12 |
Am I understanding correctly in that you didn't use an eclass to avoid |
13 |
cluttering up the main eclass directory with something specific to |
14 |
this one package? If so, it sounds like what you really want is |
15 |
per-package eclasses (maybe with elibs as well to hold the |
16 |
non-metadata code), which aren't covered by GLEP33 but ought to be |
17 |
easy enough to add. |
18 |
|
19 |
> There's a caveat here; imagine one of the current PM's processing an |
20 |
> EAPI=4 (or whatever) ebuild that uses elib- specifically there will be |
21 |
> a global scope function invocation of a function that doesn't exist. |
22 |
> |
23 |
> In the past, a minority of folk have raised complaints about this- it |
24 |
> was never stated as best I know, but my assumption looking back is |
25 |
> that it was due primarily to paludis getting pissy about ebuilds |
26 |
> outputing anything during metadata sourcing |
27 |
|
28 |
I can't speak for other people who may have complained, but it seems |
29 |
to me that for ebuilds to be calling non-existent commands is fairly |
30 |
obviously wrong, even if the consequences happen to be benign - not |
31 |
the end of the world, but something that ought to be avoided if |
32 |
possible. (As far as paludis goes, it's more stdout that it used to |
33 |
get upset about than stderr.) |
34 |
|
35 |
> Managers should implementat that functionality; orthogonal to it, |
36 |
> we've got a few options for how to deal with an EAPI=4 ebuild being |
37 |
> metadata sourced by a <=EAPI3 PM (meaning, there will be a "command |
38 |
> not found" spat to stderr during sourcing): |
39 |
> |
40 |
> [...] |
41 |
|
42 |
Regarding the stuff about other standalone repositories, I don't think |
43 |
it's a big deal to require them to carry a small amount of extra stuff |
44 |
(only if they actually start using elibs in any case), considering all |
45 |
the profiles, eclasses etc that they'd need anyway. Overlays based on |
46 |
the main Gentoo tree would be fine without any effort. |
47 |
|
48 |
(For the record, +1 for GLEP55 from me, but the reasons for and |
49 |
against don't need to be repeated yet again.) |
50 |
|
51 |
> My suggestion? Split this into two, elibs, and eclass refactoring. |
52 |
|
53 |
Per-package eclasses would be beneficial IMHO regardless of the other |
54 |
eclass stuff from 33, might be worth thinking about those as another |
55 |
item (consistent with the existing design plans of course) if the rest |
56 |
isn't going to happen soon. |