Yum deltarpm

Ahmed Kamal email.ahmedkamal at googlemail.com
Sat Jan 13 22:03:45 UTC 2007


I don't like tracking different update states too, which is why I was
suggesting previous-to-latest only drpms. Guess like what apple does.

It's not easy for me to determine whether users will like such a feature.
Most casual linux users I meet, are not keen on updating their systems. And
when they finally decide to, they don't want to download lots of megabytes.

One more scenario I could think of, is users in developing countries like
mine, where broadband is rare. Deltas make a lot of sense on a modem (tell
me about it a few years ago). Anyway, if most of you don't think this is
worth the effort, let me know about it.

Any idea if OLPC has implemented implemented something similar ?

On 1/13/07, Dennis Gilmore <dennis at ausil.us> wrote:
>
> On Saturday 13 January 2007 12:40 pm, Ahmed Kamal wrote:
> > FYI, this yum deltarpm support, is based on that same deltarpm package
> that
> > is made by suse. This suse package can create new rpms from drpm +
> (either
> > ondisk files, or old rpm). Either way, a new rpm is created, then
> > installed. Never does it replace files directly. Not sure why this would
> be
> > bad security wise
>
> I personally don't like the idea of binary delta's  there are too many
> variables  with them and too much overhead.    for instance say we update
> cups 4 times during the  life of a release.  that means we need to create
> 4
> delta's  as the end user can have 4 possible states of the package.
>
> Windows has always done  delta's  and for the longest time they only
> provided
> delta's from  the latest version.  which is the reason you had to update a
> ton of times to get to the latest version.  that has changed but its not
>
> http://www.directionsonmicrosoft.com/sample/DOMIS/update/2005/02feb/0205fsuttc.htm
>
>
> Apple also provides delta's  but they do only deltas from the previous
> version
> to latest  if you  you have an older version you have to get the full
> version.
>
> most packages are so small that i don't think the overhead is worth the
> pain.
> OOo and a couple of others i could see maybe,  but otherwise I personally
> don't think its a good idea.  It means mirrors need to carry more data.
> --
> Dennis Gilmore, RHCE
> Proud Australian
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20070114/61dcc42a/attachment.html 


More information about the infrastructure mailing list