On Tue, 10 Jun 2008 11:08:21 -0400
Richard Freeman <rich0@g.o> wrote:
> I'm curious as to what operation in particular we're looking at.
> Let's say I type in "paludis --sync":

paludis --sync doesn't use metadata.

> Next, suppose I type in "paludis -pi world":

If it's straight after a --sync, then yes, some things are pre-loaded
by rsync. Similarly, if it's straight after other operations, then yes,
some things are pre-loaded. But we don't plan for "just the use cases
that make our life easy".

> Why wouldn't everything you need not already be in the cache?  And if 
> something wasn't, then why is reading in the EAPI any slower than 
> reading in (R)DEPEND/KEYWORDS/IUSE/etc?

Currently we don't touch the ebuild's content *at all* for metadata
operations, except where there's no or stale metadata cache (which is
rare). We can get away with this currently because 0 and 1 have
identical cache layouts and PMS has some (necessary) weasel wording;
future EAPIs likely won't, so we're back to the chicken / egg problem.

So... We either have the EAPI from the extension (which we already
have, since we have to read the dir to know what versions are
available), in which case we know how to read the metadata cache file.
Or we have to open up a file that would otherwise not be opened, just
to parse one line so we know how to read the cache file.

> What specific operation (from an end-user perspective) is improved by 
> putting EAPI in the filename?  I'm not interested in theoretical 
> operations like "given a portage tree, find the EAPI of every file" - 
> users don't do those operations routinely in isolation, but as part
> of larger operations where doing an open and a getline now just
> speeds up the open and getline that would be executed 500 lines later
> anyway.

paludis -pi anything on a cold cache.

-- 
Ciaran McCreesh