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

[Gregorio Guidi <g.guidi@sns.it>]

On Wednesday 01 December 2004 11:59, Brian Harring wrote:
> On Wed, 2004-12-01 at 01:37, Gregorio Guidi wrote:
> > On Tue, 30 Nov 2004 06:22:07 -0800, Brian Harring <ferringb@gentoo.org>
>
> 1) don't modify $portdir/metadata/cache.  Modifying the rsync'd cache
> directly results in more to rsync for the next sync.  Going that route
> would result in a lot of dial up users out for blood.
> 2) the user may not be using the same cache backend as the distributed
> cache- the rsync'd cache is portage_db_flat, while the user may be using
> a custom sqlite backend.  I suspect this will be come more common place
> whenever cvs becomes stabled- the cache backend is being refactored
> currently.
> 3) cleanse stale entries from the cache, so you don't end up w/ a couple
> thousand extra files sitting in your local cache.  Stable portage
> accomplishes this by wiping *all* local cache entries, and transferring
> the *entire* rsync'd cache over.  Cvs is smarter, transfers only what
> has changed, and removes the stale entries (this is why it's faster).

I was interested exactly in points 1 and 3 (and I'm glad to hear there's even
a sqlite backend).
With respect to point 3, the solution you imlpemented is surely the right 
thing to do.
With respect to point 1, maybe a good solution could be to just check cache 
validity in $portdir/metadata when the cache is needed, and write a new cache 
in /var/cache/edb if it is not valid.

But since either a solution to point 3 or to point 1 would resolve the basic 
speed problem, the cvs implementation should be nearly optimal.

> So... that's why portage basically copies the cache to a different
> location.  If the tree were treated as readonly, and it was enforced in
> some manner, that transfer wouldn't be needed.  This is something that's
> being batted around also- the code for making the cache readonly is
> already done fex.
> ~brian
>
>
> --
> gentoo-portage-dev@gentoo.org mailing list

Thanks a lot for your answer!
Gregorio

--
gentoo-portage-dev@gentoo.org mailing list