| 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. |
Archives