Fedora 39 Looks To Use DNF5 By Default For Better Performance & Improved User Experience

[yump]

What you're probably finding slow is the constant checking for updated metadata.

If you alias dnf to dnf -C in non-root shells, it will use the system cache instead of the per-user cache. Fedora has a systemd timer that updates the system cache every hour, so you never have to wait for it to refresh just to do a dnf search or dnf info.

[Anvil]

Not in 'production', partly because it's still really pretty early, and partly as my main system is Silverblue now. I've played around with it a bit in disposable environments and stuff though.

i tend to think the only way we'll findout is when its made default in 39 if its a Memory Hogg or not

[AdamW]

have you been using it from the copr repo?

Not in 'production', partly because it's still really pretty early, and partly as my main system is Silverblue now. I've played around with it a bit in disposable environments and stuff though.

[Anvil]

Yes it will. This is one of the major benefits.

have you been using it from the copr repo?

[AdamW]

I am a bit confused. I thought dnf, especially libdnf already got rid of python in v4.

I personally would appreciate any improvement, I use fedora as my daily driver and I am happy with it, but compared to pacman dnf is painfully slow.

I don't have the insight into package managers as I once did, but as just a user it's appreciated they do work on this.

v4 kinda got half way there. It introduced libdnf and adopted libsolv, which replaced large chunks of stuff that used to be written in Python as part of dnf proper. But the core dnf project itself, as of v4, is still written in Python - https://github.com/rpm-software-management/dnf - and it's not just the CLI app, but rather more than that, including an API that several important other things still use.

DNF5 really won't have *any* Python left in the core code (it'll still provide Python bindings via swig, AIUI). I'm not sure whether it intends to somehow provide the existing python-dnf API, or if consumers of it will need to rewrite to updated APIs.

[AdamW]

Absolutely. It's written in C++ vs Python. Should be a lot faster as well.

Actually one of the main reasons it'll use less RAM is not to do with the language, but because it'll load metadata into memory as needed, rather than always loading huge amounts of it. A large part of why DNF currently uses quite a lot of RAM is that the metadata includes the path of just about every file in every package, and DNF loads all that into memory for pretty much any operation. DNF5 will only load path metadata as it needs it.

This is all AIUI, errors are mine. But there's an ongoing discussion on devel@ if you're curious: https://lists.fedoraproject.org/arch...OKYU2KZZLKC4D5

[AdamW]

will DNF5 use less RAM than DNF4 ?

Yes it will. This is one of the major benefits.

[gbcox]

What you're probably finding slow is the constant checking for updated metadata.

I believe you can adjust the checking of metadata in the dnf.conf if the default setting bothers you... although, you may not be getting the most current updates. Of course it would be nice if it were quicker, but at least for me the benefits of DNF far outweigh the few extra seconds/minutes for the metadata check. Actually, I've switched to using dnf offline-upgrade download and dnf offline-upgrade reboot so never really notice it anyway.

[Vistaus]

been rumblings for a while now in opensuse of replacing zypper with DNF, wonder if the arrival of DNF5 is moment they're waiting for.

What's wrong with Zypper? I really like the way it works. Not saying DNF isn't good (I have no experience with it), but I don't see the need to replace it.

[birdie]

will DNF5 use less RAM than DNF4 ?

Absolutely. It's written in C++ vs Python. Should be a lot faster as well.