Re: A more efficient up2date service using binary diffs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



ons, 09.03.2005 kl. 17.28 skrev Joe Desbonnet:
> Any reason why people hate it?  I really can't see any downsides to
> this as an enhancement to the current system.
> 
> I think the logic needed is something like this:
> The up2date system checks if a RPM of software to be updated is
> available locally. If not, up2date carries on as normal. If the RPM is
> available it checks for a suitable diff file in the archive. If found
> it downloads the diff, applies the patch and passes the resulting RPM
> for processing as normal. If there is no diff, up2date downloads the
> full RPM as normal.
> 
> Joe.

That could be one way to do it, saving bandwidth for users and mirrors.
But it would require the "old" version to be accessible locally, but if
you're on a modem/ISDN line, having some gig's extra used on your HDD is
way better than to download a couple of hundred MB extra.

So if you do have this archive (FC5 anaconda install option - install
local rpm repository?), yum (sorry Seth...) would download the correct
patch, apply it to the old rpm in order to create a new, fresh rpm, and
then update using that?

Hmm.. That implementation wouldn't be to bad, as nothing in rpm itself
(etc) would need to be changed, the change to yum would probably not be
enormous (correct me if I'm wrong), and it would be great for many users
and mirrors.

Kyrre


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux