From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28125 invoked from network); 1 Dec 2004 11:25:33 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 1 Dec 2004 11:25:33 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CZSc0-0005Us-Rn for arch-gentoo-portage-dev@lists.gentoo.org; Wed, 01 Dec 2004 11:25:32 +0000 Received: (qmail 28799 invoked by uid 89); 1 Dec 2004 11:25:31 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 9083 invoked from network); 1 Dec 2004 11:25:31 +0000 From: Gregorio Guidi To: gentoo-portage-dev@lists.gentoo.org Date: Wed, 1 Dec 2004 12:25:27 +0100 User-Agent: KMail/1.7.1 References: <9ef20ef3041127151046107fb5@mail.gmail.com> <200412011037.06170.g.guidi@sns.it> <1101898798.32056.124.camel@localhost.localdomain> In-Reply-To: <1101898798.32056.124.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412011225.27593.g.guidi@sns.it> X-Virus-Scanned: by amavisd-new at libero.it serv5 Subject: Re: [gentoo-portage-dev] Current portage well designed, but badly used X-Archives-Salt: ef929f4c-628c-4fd2-a716-de04b369c11a X-Archives-Hash: 1c14b020c88858c50a64d0c98173bbbb 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 > > 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