No more deltarpms by default

Pete Travis lists at
Sun Oct 19 00:20:48 UTC 2014

On Oct 18, 2014 5:00 PM, "Nico Kadel-Garcia" <nkadel at> wrote:
> On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox <gbcox at> wrote:
> > My comment was not meant to be argumentative, but rather
> > However, I do believe when changing a default, it isn't about what is
> > convenient for me.  It's about what is best for the entire community and
> > what are the real world ramifications.  I'm not buying the "let's
change the
> > default because high bandwidth is pervasive argument".
> >
> > I'll go out on a limb here and suggest:
> >
> > 1.  Most people who can afford to pay the monthly recurring cost for a
> > speed bandwidth connection have multi-core machines.
> > 2.  People who are running Fedora on multiple machines possess the
skill set
> > to easily change the default and turn Presto off if they wish.
> You left out some but related issues.
>   3) People who have a lot of hosts and high bandwidth, high speed
> local deployment requirements can, and do, set up an internal Fedora
> mirror with much lower bandwidth costs. This reduces the tangible
> benefits of deltarpms significantly. This is combined with my direct
> observation that working from plain rpms is much faster and more
> reliable. Re-assembly from deltarpms is computationally expensive and
> thus expensive for large numbers of yum clients. It sounds like a
> great idea at first glance, but it profoundly and unpredicatably
> increases the disk space and bandwidth needed for mirrors themselves
> at a relatively small benefit in download bandwidth. The great example
> of difficult to "delta RPM's" sems to be libreoffice. Between the
> compressed and distinct binaries for the war files, and the deltarpm
> process itself, they save very little bandwidth for many of the
> builkies projects.
>   4) The much, much larger source of wasted bandwidth and resources is
> the yum repodata. That's 50 Meg, every time the repodata expires or is
> updated, even if there are no actual RPM updates. And for systems that
> need frequent updates and refreshes to ensure the latest packages,
> it's consumed *every single time* you flush the metadata.
> > What about the repositories and mirrors?  Do they all have unlimited,
> > bandwidth?
> No one does. But in my direct observation, deltarpms are a
> theoretically clever attempt to solve the wrong problem, an attempt
> that requires massive *extra* diskspace and resources for the mirror
> sites that doesn't address the more consistent and demonstrable
> problem.
> There are environments where bandwidth limits are so great that even
> the bare RPM downloads are vulnerable to interruption, and the
> marginal improvement of the deltarpm would be noticeable. But I've not
> seen such an environment in roughly 10 years, and it was usually to
> some bad network hardware or local misconfiguration.
> --

Network operators will experience a real, tangible cost increase from
turning off deltarpms.  End users with metered bandwidth - off the cuff,
I'd guess hundreds of thousands of current users and billions of
prospective users - will experience a real financial impact from the 'loss'
of this feature.

Now, I realize everyone can turn this on, and everyone can turn it off.
Changing the default option doesn't take away the feature.  Those with
metered connections will probably, eventually, discover they can turn
deltarpms on.  After the first bill arrives, or the second.  These are
likely to be people with limited financial resources, using computers that
you couldn't pay me to work on these days.  We're keeping the entire 32bit
architecture alive for them; in contrast to that, the infrastructure burden
of deltarpms is slight.  Even so, we continue to welcome this demographic
to use and participate in Fedora.

Faster update transactions are good, but anyone that's concerned about the
*financial impact* of consuming extra CPU  cycles ( as in Nico's case #3)
is very likely to be employing a competent administrator (like Nico) that
should know how and why to flip the switch.  Nobody wants to take this
option away, and I doubt it  would even be possible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list