No more deltarpms by default

Jaroslav Reznik jreznik at
Mon Oct 6 14:46:22 UTC 2014

----- 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

That's one option. And I agree delta rpms optimization would be great
first step.


> --
> devel mailing list
> devel at
> Fedora Code of Conduct:

More information about the devel mailing list