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@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

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

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