[Yum-devel] yum on an olpc machine (slooooooooooow)

seth vidal skvidal at linux.duke.edu
Mon Dec 18 04:01:02 UTC 2006


On Sun, 2006-12-17 at 20:26 -0700, Michael Stenner wrote:
> On Sun, Dec 17, 2006 at 09:59:58PM -0500, seth vidal wrote:
> > we store the checksum of the old db (compressed and uncompressed) as
> > well as the new db file in repomd.xml
> > 
> > yum would download repomd.xml - if the checksum of its sqlite db files
> > is the same as the old checksum, then it downloads the sqlite
> > transaction diff b/c it can use it. when it doesn't match then grab the
> > whole file.
> > 
> > does that make sense to everyone?
> 
> This seems safe, meaning that it shouldn't lead to corruption or
> ambiguity.  Whether it provides practical improvement depends upon
> usage patterns.  In the limit that yum is run much more frequently
> than the repo changes, then a full download should be rare.  Do we
> know that to be the case? 

I think with yum-updatesd running on fedora systems it is much more
likely that people will be looking for new repodata much more often than
it is updated, yes.

>  If it's not, then keeping multiple diffs is
> always possible, although I think we all agree that the concept gets
> ugly fast and that should be avoided unless it provides a substantial
> benefit.

Seems like the order of operations would be:
1. figure out if we have any rough consensus on doing this at all.
2. write the code to add the sqlite dbs on the repo side
3. write the code to grab the sqlite dbs on the yum side
4. figure out where to go from there.


We could make steps 1-3 happen for 3.0.X w/o breaking the api

Step 4 takes more planning. For example, if we want to change the db
schema at all we'll need to version the db information, preferably in
repomd.xml so we can know what we'll get before we touch it.

-sv





More information about the Yum-devel mailing list