DNF5 delayed
DNF sits on top of the RPM package manager and handles higher-level tasks, managing the software mix on the system as a whole. It deals with repositories, manages system updates, and more. On a modern Fedora (or Red Hat) system, DNF is probably invoked by users much more often than RPM is. Given its central role, DNF has to be solid; the alternative would likely lead to the creation of wrecked systems, which is seen as generally undesirable. At its outset, DNF was not as solid as many would have liked, but Fedora users worked the kinks out of it, and it became stable enough to be used in the Red Hat Enterprise Linux products as well.
In September 2022, a system-wide
change proposal was posted, describing a plan to replace DNF with the
entirely new DNF5 package manager. DNF5, it was said, would "provide a
significant improvement in user experiences and performance
". It is a
complete rewrite from scratch, in C++, resulting in a tool that is both
smaller and faster than DNF (which is implemented in Python). The new tool
would result in less duplicated code on Fedora systems and a more robust
method of storing package metadata. It claims better integration with
PackageKit — though it is not
clear that PackageKit has a long future either. DNF5 was also planned
to have full support for Modularity; this
also has limited value now that Fedora has given up on
Modularity.
It seemed like a good plan, with only one catch: DNF is a crucial system tool that interacts tightly with a large number of other tools and much of the Fedora build infrastructure. There is little patience for instability or incomplete implementations in this area. So it was a bit discouraging that the original plan gave a long list of things needing attention and a rather shorter list of people who would be tasked with getting that work done.
Nonetheless, the change proposal was approved at the January 31 meeting of the Fedora Engineering Steering Committee (FESCo). In May, it was announced that DNF5 would obsolete DNF in the Rawhide testing distribution. In July, the DNF 5.1.0 API was declared to be stable and unchanging henceforth.
Meanwhile, though, testers were reporting a steady stream of problems. The DNF5 developers also have not yet managed to reimplement some DNF functionality; this includes small details like the system-upgrade operation, which is how Fedora users take their systems through the (twice yearly) upgrades inherent in the Fedora development schedule. As the freeze dates for the Fedora 39 release approached, the level of concern grew.
On July 13, Fabio Valentini opened a FESCo ticket, saying that the time had come to hit the "abort" button for DNF5 in Fedora 39:
The DNF5 Change was approved with the condition that bits that are important to the distribution MUST work, but this does not seem to be the case yet, six months after this was initially approved - there's at least a few things that are still using dnf-3 or have been broken since the switch to dnf5.We are now mere days before the Fedora 39 mass rebuild is scheduled to start, so I think it's time to start talking about the roadmap for getting missing pieces into place for Fedora 39, or if that is not possible within this timeframe, whether the contingency mechanism should be enacted.
The July 20
FESCo meeting concluded that an "updated list of acceptance
criteria
" was needed, and that the issue would be reconsidered at the
following meeting. The July 27
meeting subsequently decided to postpone the change. That same day,
Samantha Bueno announced
that the DNF5 postponement would not be a short one; the Fedora 40
release will be skipped, and the earliest release that might see this
change is Fedora 41, which can be expected late in 2024.
With a core system component like DNF, it's crucial that we provide a stable, complete, and thoroughly tested experience to everyone. In its current state, we would not be able to deliver that. With more time, we'll be able to regain our footing and do things properly. Furthermore, this team, which has worked tirelessly over these last several months especially, will be able to avoid burnout. This was not an easy decision to make, but it is the best decision for the team, for this project, and for Fedora.
Nicola Sella posted some suggestions for Rawhide users looking for the best way to back away from DNF5 for now.
To an outsider, it would be natural to wonder whether it was really necessary to replace a working program and put the project through this kind of disruptive transition. It is worth noting, though, that this question did not come up in the discussions of DNF5 over the last year. Fedora does not lack for developers who are willing to speak their minds when they feel that a wrong direction has been chosen, so that silence is significant. The project as a whole still seems to feel that the advantages that will come from this transition will be worth the trouble in the end.
Getting there is going to take longer than expected, though. Hopefully the
DNF5 developers will have a chance to take a break and finish the job
without the pressure of a looming release deadline hanging over them.
Replacing a tool like DNF is a job that must be done carefully; giving the
developers the time to do that seems like a wise decision.
Posted Aug 18, 2023 14:36 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Somewhat similar scenario and pretty normal part of OS development.
Posted Aug 18, 2023 15:23 UTC (Fri)
by re:fi.64 (subscriber, #132628)
[Link] (7 responses)
> it must be time to throw it away and start over from the beginning
is a rather uncharitable reading?
AIUI DNF5 is not a rewrite of *everything* developed to replace yum. In particular, libresolv is still being used (and the main draw of dnf was it using an actual dependency resolver), and libdnf5 is an iteration of libdnf. The main actual rewrite *from scratch* is the currently-Python frontend, which is where the missing plugins and such mentioned in the post come in.
Posted Aug 18, 2023 16:08 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
Yep. This looks like substantial refactoring but not a from scratch rewrite.
https://dnf5.readthedocs.io/en/latest/changes.html
Dnf4 already used libdnf and libsolv. That part hasn't changed. Dropping Python entirely on the frontend is new and is significantly faster and uses less memory (in a big part because of better metadata processing - not having to download and load the full file index of everything into memory) but the configuration format, options mostly seems to be retained from the Yum days. I suspect the disruption is mostly for those integrating with the new API (Ansible, Mock, plugins etc) and not for end users.
Posted Aug 20, 2023 11:51 UTC (Sun)
by gmgod (guest, #143864)
[Link] (4 responses)
That is very misleading. The python wrapper is very thin. I have personally profiled dnf to see if there were low hanging fruits on the python side to make things faster. The answer is no: dnf spent more than 95% of its time in C parts (libresolve and libdnf). I can't remember the actual number but it was in the very high 90s, even when metadata were already downloaded.
What makes dnf5 better are better algorithms (as implemented in libdnf5).
And the main reason they got rid of python is so that it's not pulled as a dependency in small footprint systems. Dnf5 still has a problem with memory management on those same low-footprint systems though... I did not measure it precisely but even just with "top" you can see that whatever dnf is using, it's dwarfed by metadata loading.
They tried to go too fast by reimplementing the frontend from scratch to get rid of python asap and improve the backend at the very same time but both are huge projects... It would not have been a bad idea to incrementally improve dnf4...
Posted Aug 20, 2023 15:36 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Yes, it is very misleading when you cut off the part where I attributed to the speed and memory gains to the changes in metadata processing and not the language itself.
Posted Aug 21, 2023 23:16 UTC (Mon)
by gmgod (guest, #143864)
[Link] (2 responses)
Posted Aug 21, 2023 23:30 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
There was no such subject but I understand your confusion since you read it that way.
Posted Aug 22, 2023 0:17 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
On second thought, it wasn't the subject that confused you but omitting things written as part of the same sentence - "in a big part because of better metadata processing - not having to download and load the full file index of everything into memory".
There was no implied causation between the switch of the language and that work. In fact, Yum actually did handle this part better than Dnf 4.
Posted Aug 20, 2023 16:49 UTC (Sun)
by jzb (editor, #7867)
[Link]
If taken literally. I took that as a little sarcasm or snark, not meant literally. I read that in Jon's "grumpy editor" voice, but I can see how one might read it your way.
Posted Aug 19, 2023 2:38 UTC (Sat)
by rsidd (subscriber, #2582)
[Link] (39 responses)
If it works, fix what doesn't work but why change it? Is python really the bottleneck here, and is rewriting in C++ likely to yield a more maintainable codebase?
Posted Aug 19, 2023 2:51 UTC (Sat)
by jccleaver (guest, #127418)
[Link] (19 responses)
For the life of me, I can't see why dnf is particular performance-sensitive. Getting it right is about a billion times more important than getting it fast when it comes to package management, and if you're depending on 'yum update' to run in 5 seconds instead of 12 for some critical function then you're probably doing something wrong.
Furthermore, python is still a standard piece of sysadmin toolkit, and far more grokkable at a human level than C++ would be.
If there's a time-sensitive core, sure put that in compiled code. But the closer the UI it gets I feel like the less important this should be.
Posted Aug 19, 2023 7:10 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (9 responses)
Posted Aug 19, 2023 15:02 UTC (Sat)
by meyert (subscriber, #32097)
[Link] (7 responses)
Posted Aug 19, 2023 17:21 UTC (Sat)
by smoogen (subscriber, #97)
[Link] (5 responses)
The reality is that nearly everyone using containers starts yelling and screaming that any container can't be worked on properly because they need to do all this work to make this one little thing(*) added to make it work.
(*) Narrator: It wasn't and never is one little thing. Eventually you find your 200 containers are all running their own sshd daemons, apt/dnf, and layers of additional software to make this one thing work the way you wanted it to. [And you ended up not being able to replicate that when rebuilding it.. so you have kept this artisinal container for years past its life.]
Posted Aug 19, 2023 17:43 UTC (Sat)
by amacater (subscriber, #790)
[Link] (1 responses)
It's another thing that's kept me away from using Docker extensively - you've no provenance. (I've no
Posted Aug 20, 2023 14:37 UTC (Sun)
by intelfx (subscriber, #130118)
[Link]
Posted Aug 19, 2023 18:12 UTC (Sat)
by jccleaver (guest, #127418)
[Link] (2 responses)
Admin-levels tools on real systems shouldn't be afflicted with reduced functionality and weird bugs and instability out of a need to accommodate the needs of the hyper-optimized container world.
Can size be reduced when there's low hanging fruit? Sure. But this is not that.
(See also: How systemd was pushed onto all of us)
Posted Aug 22, 2023 6:52 UTC (Tue)
by knotapun (guest, #166136)
[Link] (1 responses)
Posted Aug 22, 2023 9:36 UTC (Tue)
by zdzichu (subscriber, #17118)
[Link]
Posted Aug 24, 2023 19:09 UTC (Thu)
by jond (subscriber, #37669)
[Link]
I completely agree but the tooling to support this needs to catch up (as per smoogen’s comment)
Posted Aug 19, 2023 16:16 UTC (Sat)
by jccleaver (guest, #127418)
[Link]
Premature minimalization, like premature optimization, is the bane of a lot of annoyance at this point. Some of us still have system administration duties the old-fashioned and aren't trying to save kilobytes of space that will only come back to haunt you at 3am when you're called to go do some sort of diagnosis on it only to discover 'ping' isn't installed.
That said, for those that do need this, it seems like the easier thing would be for yum/dnf to not be installed at all. If you're already tossing out every last unnecessary byte for static images, then you should already know precisely what packages you need rpm to lay down, and you don't need a dynamic or repo-based dependency generator at all.
>In the past microdnf was used instead.
This would make sense as a replacement, but the human tool does not need to be minimized in this way. We still use bash for day-to-day scripting, not busybox, after all.
Posted Aug 19, 2023 11:19 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
It's not so much raw performance as it is outsized memory usage. Fedora has had to bump the minimal system specs solely due to DNF running out of memory when doing updates.
Posted Aug 19, 2023 15:24 UTC (Sat)
by gbailey (subscriber, #58)
[Link]
Posted Aug 19, 2023 13:02 UTC (Sat)
by vadim (subscriber, #35271)
[Link] (3 responses)
There are automated tasks, like Docker builds and CI runs that may need to call on the package manager.
And there's performance from the standpoint of an user. Slow performance can be a serious annoyance. On my high end, 16 core machine, `dnf info firefox` takes 2 seconds from a cold start, and 1.1 seconds once it's been cached. I think that's pretty bad, considering there's far slower machines out there that don't use a NVMe. There's no reason why a simple query shouldn't be near instant. On lower capability machines people may be waiting 15 seconds for an answer. Probably repeatedly if they don't get what they want on the first attempts.
And there's the metadata downloads, where you run a query and suddenly it takes 3 minutes for it to download stuff.
Posted Aug 19, 2023 16:12 UTC (Sat)
by jccleaver (guest, #127418)
[Link] (2 responses)
Posted Aug 19, 2023 19:40 UTC (Sat)
by vadim (subscriber, #35271)
[Link] (1 responses)
Posted Aug 21, 2023 16:56 UTC (Mon)
by jccleaver (guest, #127418)
[Link]
The *package manager* should, yes. But the package manager here is RPM (and librpm), which runs well, fast, and stable.
Dependency and repo management is a distinct layer on top of this, and that's what I'm suggesting doesn't need to put speed over correctness.
Posted Aug 19, 2023 19:14 UTC (Sat)
by mseeber (subscriber, #126394)
[Link] (2 responses)
Posted Aug 21, 2023 4:21 UTC (Mon)
by AdamW (subscriber, #48457)
[Link] (1 responses)
The performance improvement with dnf5 is more in the stuff that happens before the actual package operations - metadata parsing, mainly.
Posted Aug 24, 2023 14:01 UTC (Thu)
by ehiggs (subscriber, #90713)
[Link]
https://www.youtube.com/watch?v=UrZye1M-xPA
https://www.reddit.com/r/Fedora/comments/yh3p11/dnf_vs_dn...
Posted Aug 19, 2023 7:13 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
It's the same here, isn't it? New hashing or compression algorithms have been introduced over the years, but the basic rpm tooling has stayed the same and yum/dnf /zipper are all frontends to handle dependency resolution and network access.
Posted Aug 19, 2023 7:34 UTC (Sat)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Or even more accurately, apt is both the software management system, and the name of one particular front-end to it. Other front-ends exist like apt-get, aptitude, synaptic. It sounds like apt (the backend) is like libdnf. It has grown in features but not incompatibly. Meanwhile apt (the front-end) is almost drop-in compatible with apt-get, apt-cache and friends, which it replaced, and apt-get etc are still available if you want to use those.
Posted Aug 19, 2023 21:54 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Posted Aug 19, 2023 10:05 UTC (Sat)
by mokki (subscriber, #33200)
[Link] (1 responses)
Posted Aug 21, 2023 4:23 UTC (Mon)
by AdamW (subscriber, #48457)
[Link]
Posted Aug 20, 2023 19:07 UTC (Sun)
by Sesse (subscriber, #53779)
[Link] (11 responses)
But also not all that much new innovation; quality-of-life improvements (like apt-get → apt) and lots of bugfixes sure, but I can't recall anything really big since multiarch (2005) and possibly triggers (2007). dpkg is still using flat text files (one per package, read from disk on startup) for keeping track of installed files. apt doesn't have anything like libsolv AFAIK (I believe it's pretty much hand-rolled, and I still need to go to aptitude when apt can't figure out the conflicts). But it _is_ nice that it doesn't break under you, indeed.
Posted Aug 21, 2023 13:53 UTC (Mon)
by foom (subscriber, #14868)
[Link] (9 responses)
That seems to have been a fine choice, since apt and dpkg appear reasonably performant, whereas people are always complaining about how slow yum or dnf are?
Posted Aug 21, 2023 14:25 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
- dnf is a single tool that answers all my queries; I can never keep the set of apt tools for different queries straight (nevermind that some need more metadata downloaded…manually or not, I can't recall)
Posted Oct 9, 2023 8:42 UTC (Mon)
by daenzer (subscriber, #7050)
[Link] (1 responses)
metadata for apt-file is now automatically downloaded along with other APT metadata.
Speaking of metadata, dnf automatically downloading it at random times can be annoying. dnf4 has --cacheonly to avoid that, dnf5 doesn't (yet?) though AFAICT.
> - `dnf install $file` works without hassle
This works with the new "apt" frontend (as opposed to the old "apt-get" one) as well.
> - dnf won't "oh, there are no deps, but you obviously had no typos in your package name" auto-yes the "do you want to install this" prompt
The flip side of this is is that if the package name has no typos, and the package doesn't require installing any dependencies, the separate confirmation step is superfluous.
> - dnf doesn't ask me questions in the middle of an installation process
Neither does APT, it's per-package configuration scripts. (Now with debconf, at least any such questions should happen back-to-back early on; in the old pre-debconf days, they could happen more or less anytime)
Posted Oct 10, 2023 16:07 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Yes; `dnf -C info` is not uncommon in my history. Note that `dnf` does download file metadata on-demand, so you never fetch it unless using something like `dnf install */libfoo.so.*`. But it knew it needed it and updated it wanted instead of always being a separate call. It's good to know that there's at least one fewer command to care about now.
> This works with the new "apt" frontend (as opposed to the old "apt-get" one) as well.
I'll try and update my finger knowledge (`apt-get` is still in there as I think I needed it in the days before `apt` did everything and I haven't kept track of `apt` release announcements).
> The flip side of this is is that if the package name has no typos, and the package doesn't require installing any dependencies, the separate confirmation step is superfluous.
Eh, I prefer the consistent behavior more myself. There's `-y` for scripts and the like.
Posted Aug 21, 2023 15:06 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (5 responses)
It may be that RPM is even slower, I don't know. But this is not fast by any reasonable standard.
Posted Aug 21, 2023 17:44 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (4 responses)
[0 root@8ea9c2baf151 …/mkvtoolnix] cat /etc/debian_version
[0 fc38(64) root@149617e45639 ~…/x86_64] cat /etc/fedora-release
The contents of both files aren't 100% comparable, but those numbers aren't even remotely comparable. Syncing hurts very much on HDDs, that's true.
Posted Aug 21, 2023 17:48 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (3 responses)
dpkg is much faster under eatmydata, but still, reading the entire database into RAM (parsing text files line-by-line) is pretty unneeded.
Posted Aug 21, 2023 17:54 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
The next invocation should then get the whole database's data from the kernel's caches, shouldn't it? Sure, there are most likely more performant ways to store the data, or ways that would require fewer data to be read (and written, too), but does the database speed really matter that much compared to the FS syncs?
I'm talking about a system upgrade situation here, not about installing a single package.
Am I completely off base here?
Posted Aug 21, 2023 18:11 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (1 responses)
How can you do a handful of big read calls to read thousands of files? There's one for each package installed.
> The next invocation should then get the whole database's data from the kernel's caches, shouldn't it?
Parsing 600000+ lines of text (example number from my laptop) takes real CPU time, even if the I/O is free or nearly so.
Posted Aug 21, 2023 18:19 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link]
Ooooh I didn't know that. I thought it only reads the files directly in /var/lib/dpkg, not all the .list files, too. Good to know! I agree, that seems like a rather inefficient way to handle the information.
Posted Aug 30, 2023 9:04 UTC (Wed)
by jwilk (subscriber, #63328)
[Link]
It was 2010 in APT; 2012 in dpkg.
> apt doesn't have anything like libsolv
APT has supported external solvers since 2011: https://packages.debian.org/unstable/apt-cudf
Posted Aug 22, 2023 16:05 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link]
The number of repositories, the number of packages in those repositories, and the complexity of package relationships (as expressed in package metadata) continues to grow. That’s why algorithms that were good enough once upon a time need some rewriting.
At the same time old tools like yum/dnf accumulate flags and options, not always as consistently as one may like in hindsight, so some cleanup is welcome.
dnf5 tried and failed to achieve both too fast, it will take some more time to get right, that’s why the Fedora release process mandates contingency plans.
Posted Aug 24, 2023 19:07 UTC (Thu)
by jond (subscriber, #37669)
[Link]
To finally catch up with Debian? :)
> Is python really the bottleneck here
I don’t know whether it’s a performance bottleneck but requiring even a subset of the python in a core tool is problematic for small systems and containers. We use microdnf in container builds to avoid dnf/yum/python, but it can creep back in via other routes (in particular at the moment, crypto-policies-scripts is a hard dep of nss, necessary for FIPS and is a python script)
Posted Aug 19, 2023 4:17 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Aug 23, 2023 4:31 UTC (Wed)
by cozzyd (guest, #110972)
[Link]
Posted Aug 20, 2023 10:46 UTC (Sun)
by cyperpunks (subscriber, #39406)
[Link] (5 responses)
Using C++ for fresh, new projects in 2023 don't make much sense.
Posted Aug 21, 2023 3:16 UTC (Mon)
by otaylor (subscriber, #4190)
[Link]
Posted Aug 23, 2023 4:29 UTC (Wed)
by cozzyd (guest, #110972)
[Link] (3 responses)
Posted Aug 23, 2023 5:46 UTC (Wed)
by mb (subscriber, #50428)
[Link] (2 responses)
I think the opposite is true. Static linking makes a package manager more robust during updates of dependencies that it uses by itself. It's one of the few applications where static linking actually makes much sense.
Posted Aug 23, 2023 7:12 UTC (Wed)
by cozzyd (guest, #110972)
[Link] (1 responses)
I'm not sure there is an issue with a package manager updating itself unless it does something silly like reload shared libraries at run time. The replaced library is still going to be the one in its address space? I guess if you did something silly like updated libdnf without updating dnf that could in principle cause problems if the two become incompatible but that shouldn't be possible to do with dnf...
Posted Aug 23, 2023 16:36 UTC (Wed)
by mb (subscriber, #50428)
[Link]
Unless the system crashes halfway through the update.
Posted Aug 24, 2023 8:41 UTC (Thu)
by rwmj (subscriber, #5474)
[Link]
Anyway I wanted to say that I'm using dnf5 on my development server and have been for quite a few months, and in practice it works fine for all the usual tasks. So although it won't ship by default in Fedora 39, you can install it and it will work if you want to try it out.
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
I think most real-world containers in a security sensitve environment will be based on distroless, alpine or use APKO.
DNF5 delayed
DNF5 delayed
experience but would imagine the same problem will eventually hit Podman)
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
- `dnf install $file` works without hassle
- dnf tells me the versions that will be installed
- dnf won't "oh, there are no deps, but you obviously had no typos in your package name" auto-yes the "do you want to install this" prompt
- `dnf history undo` is so very nice
- dnf doesn't ask me questions in the middle of an installation process
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
bookworm/sid
[0 root@8ea9c2baf151 …/mkvtoolnix] strace -o ~/s.txt dpkg -i mkvtoolnix_79.0-0~ubuntu2304bunkus01_amd64.deb
Selecting previously unselected package mkvtoolnix.
(Reading database ... 86951 files and directories currently installed.)
Preparing to unpack mkvtoolnix_79.0-0~ubuntu2304bunkus01_amd64.deb ...
Unpacking mkvtoolnix (79.0-0~ubuntu2304bunkus01) ...
Setting up mkvtoolnix (79.0-0~ubuntu2304bunkus01) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for man-db (2.11.2-1) ...
[0 root@8ea9c2baf151 …/mkvtoolnix] grep -E 'fsync|sync_file_range|fdatasync|syncfs' ~/s.txt | wc -l
136
Fedora release 38 (Thirty Eight)
[0 fc38(64) root@149617e45639 …/x86_64] strace -o ~/s.txt rpm -Uhv mkvtoolnix-79.0-1.fedora38.x86_64.rpm
warning: mkvtoolnix-79.0-1.fedora38.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 10c052a6: NOKEY
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:mkvtoolnix-79.0-1.fedora38 ################################# [100%]
[0 fc38(64) root@149617e45639 …/x86_64] grep -E 'fsync|sync_file_range|fdatasync|syncfs' ~/s.txt | wc -l
5
DNF5 delayed
DNF5 delayed
only do a handful of big read calls, allowing for I/O speed). Unless the parsing algorithm itself is really bad, parsing several MB of data in-memory should be much faster than reading it from storage.
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
…
> If it works, fix what doesn't work but why change it?
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
DNF5 delayed
Ensuring an atomic update of the package manager and all of its dynamic dependencies seems like almost impossible in practice to me.
DNF5 delayed
DNF5 delayed
DNF5 delayed