No more deltarpms by default

[drago01]

On Mon, Oct 6, 2014 at 3:07 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>
>
>
> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
>> On 6 October 2014 09:41, Rahul Sundaram <metherid at gmail.com> wrote:
>> > Hi
>> >
>> > One of the long standing features that were enabled by default in yum is
>> > support for delta rpms.  dnf developers have disabled this and I think this
>> > change deserves a broader discussion
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1148208
>> >
>>
>> "I have an internet flatrate at 150 mbs, and downloading the full rpms
>> is ALOT faster than the the work that the delta rpms requires."
>>
>> Wow. Good to see normal users are taken into account. The main
>> argument from a distro point of view is reducing load on servers, but
>> I don't know many people on 150Mbs either. Heck, I've just tested my
>> work janet connection and that's <100Mbs in our office. At home 8Mbps
>> is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit
>> seconds, where the very slow transfer speed declines exponentially as
>> the connection progresses.)
>
>
> The deltarpms were meant to serve two purposes
>
> 1) (lesser) Address the needs of users in developing countries (where
> Fedora is fairly popular) and bandwidth concerns are very considerable.
> Many of these users have connections that are either metered or
> extremely slow, so deltarpms provides a way to get the data to them more
> economically. This of course can be handled with a non-default option,
> so we can talk about making that more discoverable if we disable them by
> default.
>
> 2) (Major) Deltarpms significantly (Kevin, can you comment with
> numbers?) reduces the load on the Fedora update servers and mirrors,
> thereby reducing hosting costs as well as increasing the efficiency of
> the available bandwidth (since smaller downloads mean you will be tying
> up the line for a shorter amount of time).
>
> It would be nice to see if we can find ways to improve the performance
> of the deltarpm reconstruction instead. Much of the time is spent on
> compression/decompression tasks which *should* be massively parallel

s/massively parallel/not done at all/ ... but we had this discussion
each time this comes up. There is no point in compressing something
just to uncompress it a few minutes later.