A more efficient up2date service using binary diffs

[Joe Desbonnet]

The problem with the file centric approach is that it is a radical
departure from the system that's in place at the moment (the system
being more than software: it's the whole process
of creating packages, testing and managing all that).

I think if this feature has any chance of making it into Fedora it
must be implemented as a layer on-top of the software that's already
there.

Joe.

On Mon, 14 Mar 2005 14:25:25 -0500, Paul A. Houle <ph18 at cornell.edu> wrote:

>         If we were designing this kind of system as if users mattered,  it might
> make more sense to make it files-centric rather than rpm-centric.  I
> really hate the idea of making the system count on having rpms available,
> because I'm not so good about keeping the original disks around.  (Plus
> the survival of optical disks is hit-or-miss.  I've had some disks that
> lasted 8 years after getting treated with moderate care,  and I've had
> other ones that I couldn't read after walking them across campus.)
> 
>         It seems just as feasable to send diffs of the ~files~ rather than diffs
> of the ~rpms~;  if we're going to go through the bother of implementing
> something like this,  it makes sense to make something that "just works"
> rather than another one of these things that almost works (or rather,
> works if you have the disks,  works if you are ready to pull the disks out
> if you have yum,  kinda might work if you have a network install,  maybe
> it won't work.)
> 
>        This should be thought of as an optimization.  If the files on the
> disk don't checksum match the rpm database,  we ought to download and
> install the new rpm.
> 
> ----
> 
>         I've always wondered if the Red Hat Network would have been more
> profitable if it had been less wasteful of bandwidth.
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>