No more deltarpms by default

drago01 drago01 at
Mon Oct 6 15:00:05 UTC 2014

On Mon, Oct 6, 2014 at 4:46 PM, Jaroslav Reznik <jreznik at> wrote:
> ----- Original Message -----
>> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
>> > On 6 October 2014 09:41, Rahul Sundaram <metherid at> 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
>> > >
>> > >
>> > >
>> >
>> > "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.
> This is a good point but even in developing countries internet access is
> getting better and better. A few years ago installation DVD was the only
> way how to access Fedora repo. It's not requested anymore. But yeah, I do
> not live there.
>> 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; we
>> should be able to speed this up by taking advantage of additional cores
>> (and hyperthreading) on the system, for example. Another option might be
>> not to bother recompressing the RPMs but instead just install an
>> uncompressed RPM (and possibly recompress it out of band if we needed to
>> keep it in the cache).
> One idea - could we do some measurements in presto code? Aka remember
> download speed for drpms, then try to rebuild a few drpms and compare
> speed. If internet connection is significantly faster, offer full rpms
> re-download. If not, continue with rebuild. I don't have really fast
> net connection, just VDSL limited to 16 mbit due to distance from DSLAM
> but still using older netbook - the first thing I had to do, was to disable
> drpms. Same my wife's laptop - any bigger update means she can't really
> work.
> That's one option. And I agree delta rpms optimization would be great
> first step.

I am not convinced that "being fast" and "download less" are mutually
exclusive when using deltas. So we should keep deltas *and* make them

More information about the devel mailing list