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 <a.badger(a)gmail.com> wrote:
On Wed, 2007-01-17 at 09:34 -0600, Mike McGrath wrote:
> On 1/17/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
> > On Wed, 2007-01-17 at 09:29 -0600, Mike McGrath wrote:
> > > On 1/17/07, Warren Togami <wtogami(a)redhat.com> wrote:
> > > > Then limit the delta to the most common update paths. If the
> > > > delta doesn't exist when the user tries, it can fall back to
> > > > the full RPM. No big loss.
> > >
> > > Does anyone track how many updates are released / day? I should
> > > tracking that, I bet its significant.
> > >
> > If you're willing to work with per-day granularity - you can do it
> > 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 redhat.com
Some of the more recent discussions::
... and google knows of others as well. Try::
Fedora-infrastructure-list mailing list