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(a)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/0205f...
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list