Fedora 40 firms up for release [LWN.net]

Fedora 40 firms up for release

Posted Apr 17, 2024 3:47 UTC (Wed) by Subsentient (guest, #142918)
In reply to: Fedora 40 firms up for release by JoeBuck
Parent article: Fedora 40 firms up for release

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.

to post comments

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.