When comparing DNF vs Conda, the Slant community recommends DNF for most people. In the question“What are the best Linux package managers?” DNF is ranked 5th while Conda is ranked 13th. 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
Pro Binary installs
They are fast and reliable as they do not need to compile before installation.
Pro Allows for multiple environments
It is great for developers since you can easily switch between complete environments with different versions of packages, for testing and development.
Pro Open source
Conda is open source and on Github, so if you see something wrong you can fix it and submit a patch.
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.
Con Doesn't have everything
Conda is relatively new and has a smaller user-base, so the set of packages available is limited.
Con No way to resume downloads
Any download that is canceled or interrupted will have to be started over from the beginning as there is no built in solution for resuming downloads.