When comparing DNF vs Docker, the Slant community recommends DNF for most people. In the question“What are the best Linux package managers?” DNF is ranked 5th while Docker is ranked 7th. 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 Allows for portable application deployment
Docker creates a single object, containing an application with its dependencies, that can be moved between any docker-enabled machines, guaranteeing the same environment for application execution.
Pro Git-like capabilities
Docker tracks changes in systems. It allows for commits and rollbacks and for quick deployment due to having to deploy only the updated code.
Pro Allows re-using components
Docker essentially allows creating boilerplate systems (a LAMP stack, for example) that can be used as a starting point on multiple projects. And you can find multiple such containers already created by people in their public registry.
Pro Automatic build
Allows automatically assembling a container from its source code.
Pro Provides easy sharing and installation of containers through a public registry
Docker allows easily pushing and pulling containers to and from their public index.docker.io registry. Additionally, dotCloud maintains a list of official repositories of the more popular containers.
Pro Works in virtualized environments
You can set up Docker within an already virtualized environment such as a virtual machine. This allows you to run Docker on Mac and Windows, among other use-cases.
Pro Low overhead
Pro Supports a wide range of isolation tools
Docker can be used with OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones, and chroot.
Pro Tool ecosystem
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.