No more deltarpms by default

Nico Kadel-Garcia nkadel at gmail.com
Sat Oct 18 23:00:19 UTC 2014


On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox <gbcox at bzb.us> wrote:
> My comment was not meant to be argumentative, but rather tongue-in-cheek.
> 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 high
> 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, cheap
> 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.


More information about the devel mailing list