LWN: Comments on "DNF5 delayed"

DNF5 delayed

mathstuf — Tue, 10 Oct 2023 16:07:10 +0000

> 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.

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.

DNF5 delayed

daenzer — Mon, 09 Oct 2023 08:42:55 +0000

> - 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)

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)

DNF5 delayed

jwilk — Wed, 30 Aug 2023 09:04:32 +0000

> multiarch (2005)

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

DNF5 delayed

jond — Thu, 24 Aug 2023 19:09:06 +0000

> I think a containerized app should never include any tools like DNF or apt, only minimal libs to support packaged application, to reduce attack surface.

I completely agree but the tooling to support this needs to catch up (as per smoogen’s comment)

DNF5 delayed

jond — Thu, 24 Aug 2023 19:07:49 +0000

> Debian recently celebrated 30 years, and dpkg and apt haven't undergone incompatible changes for, I think, at least 20 of those years?
…
> If it works, fix what doesn't work but why change it?

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)

DNF5 delayed

ehiggs — Thu, 24 Aug 2023 14:01:55 +0000

People are benchmarking it and posting results online. The results are like 66% speedups:

https://www.youtube.com/watch?v=UrZye1M-xPA

https://www.reddit.com/r/Fedora/comments/yh3p11/dnf_vs_dn...

https://www.youtube.com/watch?v=HUcWi4OUJPc

DNF5 delayed

rwmj — Thu, 24 Aug 2023 08:41:03 +0000

As others have already pointed out, this article isn't up to the usual quality of LWN. dnf5 isn't a complete rewrite. The relatively thin front end used to coordinate a bunch of existing C++ libraries has been rewritten from Python to C++.

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

mb — Wed, 23 Aug 2023 16:36:32 +0000

>The replaced library is still going to be the one in its address space?

Unless the system crashes halfway through the update.

DNF5 delayed

cozzyd — Wed, 23 Aug 2023 07:12:57 +0000

Fedora packaging policy is such that dynamic linking is required (see e.g. https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi... for a famous case). Dynamic linking is possible in rust, but without a stable ABI it's as far as I understand not really recommended or all that useful, except when exporting a C ABI. The same is kind of true for C++ except that the C++ ABI (at least with stdlibc++) is in practice fairly stable with a few notable exceptions.

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...

DNF5 delayed

mb — Wed, 23 Aug 2023 05:46:38 +0000

I do not want to talk about whether Rust supports dynamic linking (it does), but why do you think dynamic linking is especially needed for a package manager?

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.
Ensuring an atomic update of the package manager and all of its dynamic dependencies seems like almost impossible in practice to me.

DNF5 delayed

cozzyd — Wed, 23 Aug 2023 04:31:00 +0000

The other meaning of DNF is do not freeze, which is also kind of funny here.

DNF5 delayed

cozzyd — Wed, 23 Aug 2023 04:29:47 +0000

It would be ironic if a Linux package manager was written in a language that barely supports dynamic linking. But no, C++ is us not an inappropriate language for new code (nor is C, for that matter).

DNF5 delayed

nim-nim — Tue, 22 Aug 2023 16:05:44 +0000

> If it works, fix what doesn't work but why change it?

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.

DNF5 delayed

zdzichu — Tue, 22 Aug 2023 09:36:47 +0000

Please don't reopen this topic, we all had our share of flamewars a decade ago.

DNF5 delayed

knotapun — Tue, 22 Aug 2023 06:52:24 +0000

What's so bad about systemd? It seems to be an appropriate tool, in the right place. There's some rough spots, but with most things it feels appropriate.

DNF5 delayed

rahulsundaram — Tue, 22 Aug 2023 00:17:34 +0000

> There was no such subject but I understand your confusion since you read it that way.

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.

DNF5 delayed

rahulsundaram — Mon, 21 Aug 2023 23:30:16 +0000

> Don't double down on bs. The subject of your sentence was "dropping python"

There was no such subject but I understand your confusion since you read it that way.

DNF5 delayed

gmgod — Mon, 21 Aug 2023 23:16:23 +0000

Don't double down on bs. The subject of your sentence was "dropping python". At best your assumptions were wrong, at worse you just did not express yourself clearly and meant to say dropping python is new and the new metadata processing is both faster and use less memory.

DNF5 delayed

mbunkus — Mon, 21 Aug 2023 18:19:47 +0000

> How can you do a handful of big read calls to read thousands of files? There's one for each package installed.

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.

DNF5 delayed

Sesse — Mon, 21 Aug 2023 18:11:08 +0000

> If each invocation of dpkg reads the whole database, that should not take a lot of time safe for the first time — assuming reading is done with some proper chunking (meaning only do a handful of big read calls, allowing for I/O speed).

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.

DNF5 delayed

mbunkus — Mon, 21 Aug 2023 17:54:56 +0000

OK, pure conjecture here on my part garnished with some experience. If each invocation of dpkg reads the whole database, that should not take a lot of time safe for the first time — assuming reading is done with some proper chunking (meaning
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.

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?

DNF5 delayed

Sesse — Mon, 21 Aug 2023 17:48:58 +0000

dpkg syncs way too much compared to what you'd actually need, yes. It's entirely possible to fsync less and still be equally safe, so it's not like more fsyncs == safer.

dpkg is much faster under eatmydata, but still, reading the entire database into RAM (parsing text files line-by-line) is pretty unneeded.

DNF5 delayed

mbunkus — Mon, 21 Aug 2023 17:44:10 +0000

I think this might be more due to the fact that dpkg makes different tradeoffs than rpm wrt. file system security: it syncs the file system rather often. Here's a comparison of installing the same software I provide distro-specific packages for on Debian 12 & Fedora 38:

[0 root@8ea9c2baf151 …/mkvtoolnix] cat /etc/debian_version
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

[0 fc38(64) root@149617e45639 ~…/x86_64] cat /etc/fedora-release
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

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.

DNF5 delayed

jccleaver — Mon, 21 Aug 2023 16:56:26 +0000

>No, I mean, it's 2 seconds on a high end machine. I expect it's a lot longer on something like a Raspberry Pi. That's why it's a problem, the package manager should have good performance on any suitable hardware, not just the latest stuff.

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.

DNF5 delayed

Sesse — Mon, 21 Aug 2023 15:06:32 +0000

dpkg feels pretty slow to me, and it's only getting slower as a typical system gets more and more packages. I mean, even dpkg -i hello.deb (installing 277 kB of files) needs over 500 ms on a modern NVMe drive! On a HDD, we're talking about several seconds. full-upgrades can take many minutes just in unpacking packages, when the drive can sustain many gigabytes per second.

It may be that RPM is even slower, I don't know. But this is not fast by any reasonable standard.

DNF5 delayed

mathstuf — Mon, 21 Aug 2023 14:25:10 +0000

Performance has never been a huge concern of mine as yum and dnf have always been way more *useful* in my book (though I did use `apt-rpm` way back in Fedora Core days, yum eventually improved enough to prefer it, probably around Fedora 8 or so). My main preferences for yum/dnf are around:

- 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)
- `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

foom — Mon, 21 Aug 2023 13:53:24 +0000

> flat text files (one per package, read from disk on startup)

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?

DNF5 delayed

AdamW — Mon, 21 Aug 2023 04:23:51 +0000

That's not really a huge issue. We don't bootstrap new releases, they branch off rawhide. New arches have to be bootstrapped, but they happen very rarely and we do have a process for it when it's needed.

DNF5 delayed

AdamW — Mon, 21 Aug 2023 04:21:52 +0000

This won't really help that much, unfortunately. Actual package install operations are still done by RPM and are more bound by what they're actually doing than by the package management layers.

The performance improvement with dnf5 is more in the stuff that happens before the actual package operations - metadata parsing, mainly.

DNF5 delayed

otaylor — Mon, 21 Aug 2023 03:16:49 +0000

libdnf has been moving in the direction of c++ since around 2017.

DNF5 delayed

Sesse — Sun, 20 Aug 2023 19:07:11 +0000

> Debian recently celebrated 30 years, and dpkg and apt haven't undergone incompatible changes for, I think, at least 20 of those years?

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.

DNF5 delayed

jzb — Sun, 20 Aug 2023 16:49:11 +0000

"is a rather uncharitable reading?"

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.

DNF5 delayed

rahulsundaram — Sun, 20 Aug 2023 15:36:10 +0000

> That is very misleading. The python wrapper is very thin

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.

DNF5 delayed

intelfx — Sun, 20 Aug 2023 14:37:16 +0000

Docker and Podman reimplement the completely identical underlying idea, so I see no reason why the same problem that supposedly applies to Docker should _not_ hit Podman.

DNF5 delayed

gmgod — Sun, 20 Aug 2023 11:51:24 +0000

> Dropping Python entirely on the frontend is new and is significantly faster and uses less memory

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...

DNF5 delayed

cyperpunks — Sun, 20 Aug 2023 10:46:01 +0000

Why not go for Rust when a migration from Python is needed?

Using C++ for fresh, new projects in 2023 don't make much sense.

DNF5 delayed

ballombe — Sat, 19 Aug 2023 21:54:41 +0000

apt was written in C++ from the start.

DNF5 delayed

vadim — Sat, 19 Aug 2023 19:40:14 +0000

No, I mean, it's 2 seconds on a high end machine. I expect it's a lot longer on something like a Raspberry Pi. That's why it's a problem, the package manager should have good performance on any suitable hardware, not just the latest stuff.

DNF5 delayed

mseeber — Sat, 19 Aug 2023 19:14:16 +0000

DNF is used in RPM based yocto builds. The step that installs all packages into the image can take quite a big part oft the build time in some cases, so i think speedups are welcome there.

DNF5 delayed

jccleaver — Sat, 19 Aug 2023 18:12:22 +0000

That's great, but that's container-world's problem to deal with.

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)