| 1 |
On Tue, 10 Jun 2008 19:54:33 +0530 |
| 2 |
"Arun Raghavan" <arunisgod@×××××.com> wrote: |
| 3 |
> Well, most file systems have a local structure for this data (=> block |
| 4 |
> group), so it's not going to be a seek that's very far. Secondly, how |
| 5 |
> many ebuilds do you need to read directly to get this data in a |
| 6 |
> typical case? Isn't this what the metadata cache is for? |
| 7 |
|
| 8 |
It's a nice local structure when you're just using a) a nice, linear, |
| 9 |
readahead-friendly-ish slurp of the ebuild directory and b) a nice, |
| 10 |
linear slurp of files in the metadata cache, which is how things are |
| 11 |
now. When you move that to having to make alternating use of the |
| 12 |
metadata cache and the ebuild files, you're suddenly seeking backwards |
| 13 |
and forwards between two places over and over. |
| 14 |
|
| 15 |
> >> > - it heavily restricts future syntax and meaning of EAPIs |
| 16 |
> >> |
| 17 |
> >> Not by much. It's just a header. |
| 18 |
> > |
| 19 |
> > <!-- EAPI="3" --> |
| 20 |
> |
| 21 |
> Do we want to keep the spec so wide open that we support any format |
| 22 |
> under the Sun that we fancy? Seems like overgeneralizing to me. |
| 23 |
|
| 24 |
We want to keep it open enough that we're not going to have to go |
| 25 |
through yet another backwards compatibility breaking change. |
| 26 |
|
| 27 |
-- |
| 28 |
Ciaran McCreesh |
Archives