When comparing DNF vs Flatpak, the Slant community recommends DNF for most people. In the question“What are the best Linux package managers?” DNF is ranked 5th while Flatpak is ranked 11th. The most important reason people chose DNF is:
Binary diffs for smaller downloads
Ranked in these QuestionsQuestion Ranking
Pro Delta RPMs
Binary diffs for smaller downloads
Pro Download multiple packages simultaneously for faster downloads
DNF can download packages concurrently for faster downloads.
Far more reliable that the alternatives due to solid architecture and sophisticated dependency resolution algorithms.
Pro User-friendly output
The output of DNF is helpful, clearly explaining what's happening and laying results out after a command completes.
Pro Well documented
Fully documented, unlike some of the alternatives (cough apt-get cough)
Pro Fast dependency resolution
DNF uses a SAT solver for dependency resolution. This brings even more speed and avoids dependency hell.
Pro Powerful debug options
Pro DNF is a complete tool
You can install flatpak packages on any distro you want.
Pro Application sandboxing
All applications are limited to a set of predefined permissions, enhancing privacy and security.
Pro A well-written documentation
Pro Flexible runtime management
You can install a lot of runtimes for different apps, making applications a lot more compatible while still allowing some applications to share their runtimes.
Con Poor design is one of the reasons it feels slow and unresponsive
Why not to build all metadata after all metadata downloads? Instead of download-build, download-build... Why not to show more details what it exactly doing for example on startup, on "running transaction test/check"? Pacman shows progress of these steps and does not feel so verbose even in comparison with DNF.
Con Metadata can't be downloaded in parallel
Instead of slow decompression (but less downloading) of zchunk metadata introduced in Fedora 30, this may be helpful for slow metadata downloads.
Con Dependency resolving may be slow
I can't believe in that, but sometimes it looks like that's true. Maybe the reason is that DNF does not cache its resolves and re-resolving every time or so.
Con TAB key auto-completion is pathetic
dnf ins[TAB] [TAB]... Wait 3-10 seconds (you cannot type nor clear text) and hope for some auto-completion (as far as I know it even might not auto-complete sometimes).
Con Too slow startup on HDD
For showing its usage and do nothing, DNF takes about 1-3 seconds for first startup and 0.300 seconds (300ms) for next startups on HDD.
For comarison: APT 0.015s (15ms), Pacman 0.015s (15ms), YUM 0.200s (200ms), Zypper 0.050s (50ms).
Con Does fsync very often
As a result, DNF (and whole system) on HDD becomes very slow.
Con May use up to 2 GB of RAM
Don't believe me? Simply type dnf repoquery -l and enjoy unresponsive system.
Con Very slow
Being built natively in Python, DNF is significantly slower than other popular binary package managers for Linux. But a lot is converted now to c languages, so it’s not that slow anymore.
Con No good front-end available
DNF has a few front-end options, but none of them are very good. DnfDragora takes multiple minutes to initialize its package list, operates very slow in some cases, and it has several bugs that can crash the application. GNOME Software interfaces fairly well with DNF through PackageKit, but there are still sometimes issues with instability and packages failing to install.
Con Not yet at feature parity with YUM
As DNF is the successor to YUM, it still has a lot of features that are in YUM but that are missing here. Things like skipping broken package during install, debug, verbose output, enable repo or exclude packages during install have little to no support in DNF.
Due to the way Flatpack handles packaging, this can lead to a large cache being created which quickly inflates to unreasonable sizes. Not only this, but using flatpack requires a large chunk of space to be reserved for it's own file hierarchy.