Appreciating everyone's help, it seems others have attempted this before. Anyway, let's put this through the test of time :) Also, I totally agree with keeping drpms only if they meet certain criteria, i.e. provide >50% savings or similar.

Right now, I am trying to figure out how/where the server side will store the drpm metadata. Other.xml.gz seems like a good place, or maybe a new drpm.xml.gz, but I am not sure how such file should be written. Should I just write code that will generate drpms, and that xml metadata file too ? Must the xml file be written according to a specific form, I only need to attach a hash to each drpm, which the clients will use to know whether using the drpm will be successful.

On 1/18/07, Toshio Kuratomi <> wrote:
On Wed, 2007-01-17 at 09:34 -0600, Mike McGrath wrote:
> On 1/17/07, seth vidal <> wrote:
> > On Wed, 2007-01-17 at 09:29 -0600, Mike McGrath wrote:
> > > On 1/17/07, Warren Togami <> wrote:
> > > > Then limit the delta to the most common update paths.  If the desired
> > > > delta doesn't exist when the user tries, it can fall back to download
> > > > the full RPM.  No big loss.
> > >
> > > Does anyone track how many updates are released / day?  I should start
> > > tracking that, I bet its significant.
> > >
> >
> > If you're willing to work with per-day granularity - you can do it with
> > repoquery. Just compare the changes in 'updates-released' from one day
> > to the next.
> >
> > Keep in mind the package doesn't always go up. Sometimes old pkgs get
> > removed. So it could remain the same number but new pkgs are released.
> >
> > -sv
> i think a lot of this has been discussed before in Fedora.  Anyone
> know of any threads we can point Ahmed at?  Looks like there's a lot
> of work to be done :-D

The first thread I'm aware of was in 1998 and involved xdelta'ing the
rpm's.  Google can't locate it so I'm betting it was on contrib-list
(whose archives have disappeared from

Some of the more recent discussions::

... and google knows of others as well.  Try:: delta rpm


Fedora-infrastructure-list mailing list