On Tue, 10 Jun 2008 11:08:21 -0400 Richard Freeman <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
