Red Hat Bugzilla – Bug 1148208
[rfe] enable deltarpm support by default
Last modified: 2015-11-30 04:18:15 EST
Description of problem:
Since Fedora 12 or so (my blog post on this at http://mether.wordpress.com/2009/10/01/fedora-12-and-yum-presto-plugin/) deltarpm support has been available by default for many users. dnf should enable this configuration by default as well
Use cases at
Hi Rahul, using deltarpm is not always faster. It depends on machine and internet connection. Let's wait till F22 and if more users will prefer it by default, we will change it.
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.
This is specialy true if the updates are 'only' up to 50-100 mb but contain alot of files.
I understand that for some users delta rpms are not needed and this remains a configuration option but the question is whether delta rpms are beneficial and desired by users in general.
My preference is to enable it. While my home connection is fast and not capped, the situation changes when I travel. In that case, I have to take what I can get for connectivity.
That being said, will yumex still be used, only with dnf instead of yum? If so, why not add a checkbox under Options for use of delta rpms? That would make it easy to enable/disable as desired.
Delta rpms always save me time over doing full package downloads for updates. I vote for making delta rpms enabled by default in dnf. Either way, as long as it's a user configuration option to have it enabled or disabled, I'm good with that.
original purpose of turning deltra-rpm's on by default for yum was so that
providers could save bandwidth, and thus, lower operating costs.
what has changed to remove this default.
Please bring it back or give asome indications or give some option to set it by default.
I at India, value my bandwidth and its costs.
I've always disliked delta rpm and believe it shouldn't be active by default.
If someone has a cap or low bandwidth they are free to enable it, why inflict the delta rpm on those who don't need it!!
(In reply to Stephen Haffly from comment #4)
> That being said, will yumex still be used, only with dnf instead of yum? If
> so, why not add a checkbox under Options for use of delta rpms? That would
> make it easy to enable/disable as desired.
Yes, yumex will still be used
I not sure if low level dnf options fits into yumex, it is easier to set them directly in dnf.conf.
I vote for delta rpms. Three of my computers are in separate rooms, and not on same network domain. Download time is significant via wi-fi.
And it would be useful if deltas worked with network installations.
By the way, I would very much prefer to obtain the kickstart file, and create my own DVD images. And hopefully those dvd images are in compressed mode. (deltas)
I use delta rpms all the time because most of the connections I am on are limited to 3 Mbps down. Thankfully I have not had to deal with data caps, but those are becoming more common now thanks to AT&T, satelite internet and mobile broadband. I and I believe others are still benefited by delta rpms as opposed to those who aren't.
(In reply to kksheth from comment #6)
> original purpose of turning deltra-rpm's on by default for yum was so that
> providers could save bandwidth, and thus, lower operating costs.
This is indeed THE point wrt default setting. Users can adjust the configuration to match their preference at their discretion, providers like mirrors can not.
If you want to have feedback beyond "I like it", "I hate it", ask from Fedora infrastructure people, not users.
Right, some like it, some don't. If you don't like it, you have the right to change it in conf. Closing this survey.
Some of the options have certain tradeoffs and so it is natural for people to have their preferences but this isn't a good reason to change the defaults from yum without a strong rationale to do so to minimize the pain of transition.
Regardless of that, at the minimum, this needs to be documented as a difference in https://rpm-software-management.github.io/dnf/cli_vs_yum.html
This was an accepted feature for F11. (http://fedoraproject.org/wiki/Features/Presto). Undoing that should logically be done at the same level. It's obviously okay for this to be the default configuration for the software wen it's not our default package manager, but if DNF is to replace Yum, this needs to be part of that conversation.
* file a new change
* update http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF with a note that deltarpms will be off by default, and file a ticket with FESCo noting the change to the feature.
(Side note: maybe the plugin could be dynamically enabled or disabled based on a download speed threshold?)
(In reply to Matthew Miller from comment #14)
> This was an accepted feature for F11.
> (http://fedoraproject.org/wiki/Features/Presto). Undoing that should
> logically be done at the same level. It's obviously okay for this to be the
> default configuration for the software wen it's not our default package
> manager, but if DNF is to replace Yum, this needs to be part of that
> Please either:
> * file a new change
> * update http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF with a note
> that deltarpms will be off by default, and file a ticket with FESCo noting
> the change to the feature.
> (Side note: maybe the plugin could be dynamically enabled or disabled based
> on a download speed threshold?)
I think it's enough to be part of DNF as default change for F22.
On the other hand, I'd like to see some sort of benchmark - compare internet connection speed to download drpms, try rebuild, get results and offer user choice if one of two options is significantly faster.
Delta RPMs are one of the ( i repeat, only one of the) primary reasons why I choose Fedora over other distros. It saves a hell lot of time and bandwidth. Not everybody is on an unlimited data transfer line.
I am from India and currently staying in Singapore. Right now, I have a 100 Mbps unlimited connection from Singtel at a very affordable price and everything is good. However, back at home (which I will return to, sometime, for sure), same is not the case. For the same price that I pay in Singapore, I was getting a 2 Mbps line capped at 40 GB from a local provider Airtel. It makes a huge difference over there to have deltarpms or not. From my experience, 90% of the times, delta rpms save both time and bandwidth for me even on a fast connetion.
However, we can sure tune the use of delta rpms a bit. For example, for updates that are less than 10-15 MB in size, we can avoid using the delta rpms as the time taken in download+merging (or whatever it is called) of delta rpms and original rpm can make the time difference less significant and bandwidth saved is also not much.
But having delta rpms enabled by default is needed for sure. There is no question about it. I strongly oppose the inconsideration of all those who have the liberty of having a fast and are supporting disabling of delta rpms without thinking about others. I am sorry if my tone is not appropriate here.
I really dont see what all the fuzz is about.
1. dnf supports delta rpms.
2. fedora repos has deltarpms.
This is the most importent fact.
if it's on or off by default, it just depends on who has to turn it on or off
the importent is that you can use deltarpm is you like.
What about the updates through the gui in Fedora Workstation (Gnome-software) does it use deltarpms ?, it dont uses dnf configuration.
We have the same dnf package for Workstation, Server & Cloud, deltarpms could make sense for Workstation, but does it for Server and Cloud ?
For maintaining compatibility with Yum, deltarpm will be set by default in DNF 0.6.3.
I have a normal Austrian residential broadband connection. Even there, it is still much faster to just download the full RPMs than to use delta RPMs. And parallelization (as others in the thread have suggested) will not help at all on the single-core machine I'm typing this on.
IMHO, enabling delta RPMs by default has always been a mistake!
Single-Core? Really Kevin? Even the One Laptop Per Child machines are dual-core. ;-)
Consider the worst case scenario of both options:
(a) deltarpm enabled: users with incredibly fast 24/7 internet connections will get slower but still acceptably fast updates.
(b) deltarpm disabled: users trying to get updates over slow/unreliable connections will need 5-10 times longer for already very slow updates. The worst case can hit travellers who may have very limited time at hotspots and less than comfortable keyboards to research and edit configuration files.
dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21 has been submitted as an update for Fedora 21.
Re comment 11, I think the expected impacts on users should matter at times where Fedora decides on features/changes. I certainly like deltas and see no point in spending energy, bandwith and time downloading redundant stuff
Package dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.6.3-2.fc21 hawkey-0.5.2-1.fc21 dnf-plugins-core-0.1.4-1.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Like some pointed out, not everyone is on fast unlimited connections. We need to look at the majority of users, and if we consider OLPC (which I think most of its users are in areas without good internet coverage) and the bulk of internet users, they don't have great access.
The internet connection at the off-campus apartment is slow and capped (2Mbps), back at home it's unlimited 24Mbps. Most of my time is spent at college which means I'm using the 2Mbps most of the time. DRPMs are useful, and such a case isn't rare or uncommon.
If we talk about most users, I'd say the majority has at least dual-core. Even on an i3 compiling drpms isn't that time consuming, IMO.
Why not leave delta on by default, and instead have those who find downloading the whole rpm faster disable the option? Default matters, because most users stay on default.
Perhaps we should implement better heuristics for whether to enable deltarpms rather than simply defaulting to 'yes' or 'no'.
Most of the machines I use have a gigabit Ethernet connection to a local mirror which only carries the real RPMs. And now they are downloading deltarpms over the ADSL line instead, which is slower even though it's smaller, and costs money because bandwidth is metered during the day. And then they're spending even *more* time rebuilding the package from the delta.
Well IMO Server/Cloud machines should have deltarpms off by default. I'm sure
at least Cloud images should.
Inter-link with mock issue.