On Mon, 24 Dec 2007 11:19:18 +0000 Steve Long <[EMAIL PROTECTED]> wrote: > > Which is fine. But then, the majority of devs shouldn't expect to be > > able to provide opinions when it comes to the more technical > > aspects. > > > Yes, but they can smell a nasty hack when they see one; starting with > the fact that the API is no longer as clean.
Clearly not... > >> On a somewhat related note : I noticed that among the massive > >> thread, you have brought up several times the issue of cache > >> generation, saying that it was a complicated process. > >> > >> Maybe this process needs to be reworked before the whole EAPI issue > >> can be resolved? > > > > That's partly what the GLEP is doing. Making it any simpler, > > unfortunately, would involve either a huuuuuuge performance hit > > (we're talking two orders of magnitude here) or removing metadata > > from the ebuilds entirely -- neither of which are viable solutions. > > > Oh, I thought this wasn't about performance? Nor indeed about cache > generation. The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. In particular, making a typical emerge -pv world take of the order of 0.1s per c/p-v's metadata that's needed (as a very rough idea, we're talking a thousand upwards of these on a typical system) isn't even remotely feasible. And no, the GLEP doesn't directly address cache generation. But equally, it can't ignore it simply because without some form of static metadata cache package managers can't be implemented in a way acceptable to end users. You see, there's this thing called the "big picture"... -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
