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