No more deltarpms by default

[Stephen Gallagher]

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; 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141006/be02c5f4/attachment.sig>