Fedora 40 firms up for release [LWN.net]

Fedora 40 firms up for release

Posted Apr 17, 2024 0:43 UTC (Wed) by JoeBuck (subscriber, #2330)
Parent article: Fedora 40 firms up for release

I won't miss delta RPMs. When present, they typically save well less than half a percent, and the extra complexity isn't worth the tiny savings.

to post comments

Fedora 40 firms up for release

Posted Apr 17, 2024 0:56 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> I won't miss delta RPMs. When present, they typically save well less than half a percent, and the extra complexity isn't worth the tiny savings.

While I agree that delta RPMs are likely not worth the effort for many today, I have to note that when it originally introduced in Fedora the percentage of download savings was regularly well over 50% and sometimes over 90% as seen for instance in the test results from 2009.

https://fedoraproject.org/wiki/Test_Day:2009-04-16_Presto

This was a frequent source of delight for users at that time and I am glad Jonathan Dieter, a community volunteer stepped up to make this happen along with others in Fedora. In recent releases however, it appears that Fedora infrastructure stopped producing the delta RPM packages consistently resulting in the advantages largely being lost. Hopefully broadband internet access has caught up elsewhere in the world that this isn't a barrier to getting updates.

Fedora 40 firms up for release

Posted Apr 17, 2024 3:47 UTC (Wed) by Subsentient (guest, #142918) [Link] (4 responses)

The problem with delta RPMs for me is the extra CPU overhead.
It's not uncommon at all for me to be running some weak silicon that can download all 1GB of updates in a minute or two, but takes forever to rebuild RPMs from .drpms.

I get the noble intention, but if you're dealing with weak hardware, the savings is usually not worth seeing all your cores maxxed out for 10 minutes straight.

Fedora 40 firms up for release

Posted Apr 17, 2024 21:08 UTC (Wed) by jccleaver (guest, #127418) [Link] (3 responses)

>The problem with delta RPMs for me is the extra CPU overhead.
>It's not uncommon at all for me to be running some weak silicon that can download all 1GB of updates in a minute or two, but takes forever to rebuild RPMs from .drpms.
>I get the noble intention, but if you're dealing with weak hardware, the savings is usually not worth seeing all your cores maxxed out for 10 minutes straight.

The answer, of course, is to do both. Have full RPMs for those who have lots of bandwidth and little CPU, and deltarpms for those on weak connections running normal box, or a VM on a normal box. The kvetching about the time/energy used to create deltarpms when high-compression and compute-intensive actions being done once for the benefit of many users always seemed symptomatic of larger problems with Fedora Linux as a whole -- near-complete obliviousness to the myriad use-cases out there.

Lesson learned: If someone on the systemd team or anywhere else isn't actively affected by an issue or use of a feature that you are, don't rely on it in Fedora Linux, because it'll be pulled whenever someone decides to toss out the babies to scratch a bathwater itch.

Fedora 40 firms up for release

Posted Apr 18, 2024 7:59 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

The most glaring problem with delta-rpms is how to create the for all the combination of package versions which may be involved in the upgrade. No one found a viable solution for that.

Fedora 40 firms up for release

Posted Apr 24, 2024 0:37 UTC (Wed) by motk (guest, #51120) [Link]

Uh, what does systemd have to do with this?

Fedora 40 firms up for release

Posted Apr 24, 2024 10:02 UTC (Wed) by farnz (subscriber, #17727) [Link]

I just looked over my logs for Fedora 39; for various reasons, delta RPMs have cost me more network transfer than they've saved (usually because the kernel's delta RPMs did not reconstruct cleanly, so having downloaded a 20 MiB delta, it's followed up by downloading the 100 MiB full RPM).

So, the tradeoff with the current state of delta RPMs is you either use less CPU and less network transfer by not using delta RPMs, or you use more CPU and more network transfer to do delta RPMs then fall back to downloading the full RPM. And that's on the basis that you update daily, and thus the current generation strategy of only producing a delta against the previous RPM version actually creates deltas you can use; if you update less frequently (to reduce the amount of network transfer you use for metadata), you get access to fewer deltas, since you're more likely to have missed an intermediate update.

If people actually cared about delta RPMs, they'd be working on fixing those issues; but nobody cares, so they're getting disabled instead.

Fedora 40 firms up for release

Posted Apr 18, 2024 14:49 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I remember filing an issue to first check HEAD for the drpm manifest file's size before downloading it. If it was bigger than the proposed transaction's download…just don't as the manifest will eat up any and all savings the drpms might at that point. That did get fixed IIRC. When trying to save network, one needs to check *all* network downloads on the way to computing such savings.