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
http://www.directionsonmicrosoft.com/sample/DOMIS/update/2005/02feb/0205fsut...
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list