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

Jeremy Katz katzj at redhat.com
Tue Dec 19 16:42:00 UTC 2006


On Sun, 2006-12-17 at 23:01 -0500, seth vidal wrote:
> 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.

Only for people that are always online.  And those people tend to be the
people with a faster connection for whom a diff format matters a bit
less :/

Also, if they're running yum-updatesd then it's a lot less likely that
they're waiting on metadata download/import anyway.  So they're not the
people that are complaining AFAICT.

> >  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

Yeah, but why destabilize 3.0.x with it?  Let's get it working on HEAD,
see what the benefits are and then figure out if it's worth moving back
to the old branch.  That's my $0.02 anyway.

Jeremy




More information about the Yum-devel mailing list