| 1 |
>>need help ? |
| 2 |
>>I'd like to work on the cache part, since I'm getting sic of "emerge rsync". |
| 3 |
> |
| 4 |
> |
| 5 |
> A big change in what I have, which is not nearly workeable yet (and I won't |
| 6 |
> work on it at all until august) is that it tries to use lazy evaluation |
| 7 |
> techniques combined with in memory caching. When you open an ebuild object you |
| 8 |
> can do with it whatever you want but the actual file is only read at the |
| 9 |
> moment you request the value of a property other than the version. Similarly |
| 10 |
> the packages in a category are only requested on demand. Searching (emerge -s |
| 11 |
> like) uses a smart strategy using the glob function ;-). The cache |
| 12 |
> precalculation should not be necessary for the full rewrite. |
| 13 |
|
| 14 |
|
| 15 |
Paul, |
| 16 |
|
| 17 |
do you think end-users need all ebuilds ? I have a laptop, and fetching |
| 18 |
the whole portage tree doesn't make any sence, since I emerge only a few |
| 19 |
apps. On the other hand, I'd like to fetch a "pre-computed" cache or |
| 20 |
world file, and fetch only ebuilds when necessary (emerging a package |
| 21 |
for example). Those "emerge rsync" are way too long, and can be |
| 22 |
drasticly reducted using a different way of thinking. |
| 23 |
|
| 24 |
Of course, the whole portage tree could be installed, as it is in FreeBSD ;) |
| 25 |
|
| 26 |
-- |
| 27 |
gentoo-portage-dev@g.o mailing list |
Archives