No more deltarpms by default

[Nico Kadel-Garcia]

On Mon, Oct 20, 2014 at 6:40 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
> Am 20.10.2014 um 12:31 schrieb Gerd Hoffmann:
>>
>> On Fr, 2014-10-17 at 11:49 +0000, Andre Robatino wrote:
>>>
>>> Roberto Ragusa <mail <at> robertoragusa.it> writes:
>>>
>>>> Are compressed rpms completely impossible to diff efficiently by rsync?
>>>
>>>
>>> In a word, yes. They're already compressed, so it's unlikely there would
>>> be
>>> any matching blocks between old and new rpms for rsync to take advantage
>>> of.
>>
>>
>> Years ago I saw rsync being patched for this (done by suse IIRC).
>>
>> Basic trick is to teach rsync to unpack/repack rpms, thereby effectively
>> rsyning the files within the rpm, which works *alot* better than using
>> the compressed rpm payload
>
>
> and has exactly the same result as deltarpm now where the most performance
> drop is repack the RPM based on the delta - you you are doing exactly the
> same more complex and introduce additional software in the mix

It also creates a profound computational burden on the client and
server, and it also doesn't work well for tools like libreoffice,
whose component filea are also pre-compressed into war files. "Hey, if
we keep compressing it, we'll get it down to size zero and won't use
any bandwidth".

I'm just not finding justification for deltarpms in scaleable
environments, even though my estimates of the cost of 'repodata'
synchronization were way overblown.