Duncan <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 11 Jun 2008 12:52:24 +0000:
> Ciaran McCreesh <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Tue, 10 Jun > 2008 15:00:18 +0100: > >> On Tue, 10 Jun 2008 09:49:04 -0400 >> Richard Freeman <[EMAIL PROTECTED]> wrote: >>> 4) Putting EAPI inside the ebuild, but in a manner that does not >>> require sourcing using bash (ie comment at top of file). > >> - it doubles the number of file reads necessary during resolution. > > No comment, except that it should be cached after the first one, so the > second read should be a memory read. Yeah, replying to myself... Having read the metadata-file/ebuild discussion, I see that despite the current sourcing "requirement", it's not being done in practice for dependency building during which the EAPI is a necessary data point. Only the metadata is being read, thus speeding up the process where seeks between metadata and the ebuild would otherwise be needed. While a single additional seek per ebuild would suffice (it'd be in cache after that), that could still add up to a LOT of extra seeks (with the resultant time and cache usage increase), especially on an --emptytree world or similar. Still, it's essentially required by the current spec even if the now- current EAPIs manage to avoid it due to similarity of the current EAPIs, so it'd be no new imposition. The question then becomes, if everything else needed is stored in the pre- generated metadata cache, why isn't this? Shouldn't it be there along with the rest of the (meta)data used for building the dependency tree, thus avoiding the extra seek? Why not put it in the ebuild as is the dependency data, then along with said dependency data, copy it to metadata cache when it's generated? As for backward compatibility on the metadata, append or separate (single per repository) file. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
