A more efficient up2date service using binary diffs
Joe Desbonnet
jdesbonnet at gmail.com
Mon Mar 14 19:48:14 UTC 2005
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
>
More information about the fedora-devel-list
mailing list