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://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20070114/61dcc42a/attachment.htm>
More information about the Fedora-infrastructure-list
mailing list