Re: [gentoo-portage-dev] Current portage well designed, but badly used

[Jason Stubbs]

On Wednesday 01 December 2004 22:25, Gregorio Guidi wrote:
> Nah, it would be something like:
> - see if cache exists in /var/cache/edb (one cheap access() call)
>  - if it exists, validate (costly stat() calls, but 99% success)
>  - if it does not exists or is not valid, read cache in $portdir/metadata
> and validate (stat() calls, 99% success).
>  - if cache is not valid, create new cache in /var/cache/edb (ebuild
>   sourcing: takes a lot of times).
> - read cache.
>
> - after emerge sync, go through cache files in /var/cache/edb (usually not
>   many) and remove entries corresponding to deleted ebuilds.

You've just described what portage does with almost perfect accuracy. Let me 
rearrange it for you:

> - see if cache exists in /var/cache/edb (one cheap access() call)
>  - if it exists, validate (costly stat() calls, but 99% success)
>  - if cache is not valid, create new cache in /var/cache/edb (ebuild
>   sourcing: takes a lot of times).
> - read cache.

> - after emerge sync, go through cache files in /var/cache/edb (usually not
>   many) and remove entries corresponding to deleted ebuilds.
>  - if it does not exists or is not valid, read cache in $portdir/metadata
> and validate (stat() calls, 99% success).

If /var/cache/edb is not valid during standard emerge operation, there is 
almost no chance that $portdir/metadata will be valid.

Please do some research before putting forth any more "new" ideas. The code is 
not easy to read, but is getting better. However, unless you're willing to 
put in the effort of deciphering it, making suggestions is by no means 
helpful.

Regards,
Jason Stubbs



--
gentoo-portage-dev@g.o mailing list