# dnf

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/dnf

## Quick definition

DNF is a tool for managing software on Linux systems. It lets you install, update, and remove programs with simple commands. DNF automatically figures out what other software your new program needs and installs that too. It also keeps track of what you have installed and can clean up unnecessary files.

## Simple meaning

Imagine you are moving into a new apartment and need to furnish it. You have a list of furniture you want to buy, like a bed, a table, and a chair. When you go to a store, you find that the bed needs a specific type of mattress that isn't included. Without help, you might buy the bed but then realize you cannot use it because the mattress doesn't fit. DNF is like a very helpful store assistant who knows all the requirements for every piece of furniture. When you ask for a bed, the assistant brings you the bed, plus the correct mattress, the right bed frame, and even the screws needed to assemble it. The assistant also makes sure nothing is missing and that all pieces fit together perfectly. If you later decide you no longer need the chair, the assistant will also take away the matching footrest that came with it, so your apartment stays uncluttered. In the same way, DNF installs a software package along with all its dependencies other software libraries that program needs to run. It also watches for conflicts, like two programs wanting to use the same file in different ways, and prevents those problems. DNF keeps a record of everything installed, so when you remove a program, it can also remove the dependencies that are no longer being used. This keeps your Linux system clean and efficient. On some systems, you might use older tools like YUM, but DNF is newer and faster, with better dependency handling and more consistent behavior. It is the default package manager starting with Fedora 22 and is also used in RHEL 8 and CentOS 8 and later versions.

Think of DNF as a combination of a shopping assistant, a librarian, and a janitor all in one. As a shopping assistant, it finds the software you want from online repositories vast collections of software stored on servers. As a librarian, it catalogs what you already have and cross-references it with what's available. As a janitor, it cleans up after itself, removing orphaned packages that no other program needs. This integrated approach means you rarely have to manually hunt for libraries or delete leftover files. The name "DNF" stands for "Dandified YUM," a playful upgrade from the older YUM tool, much like a dandy would improve an old outfit. In practice, DNF reads configuration files to know which repositories to contact, downloads package metadata, resolves the dependency tree using advanced algorithms, and then fetches and installs the packages in the correct order. This entire process is designed to be safe and reversible, which is critical for system stability. For any IT professional working with Linux servers or desktops, understanding DNF is essential because it is the primary way to keep software up to date and secure.

## Technical definition

DNF, short for Dandified YUM, is a software package manager for RPM-based Linux distributions. It manages packages, which are archives containing compiled binaries, configuration files, metadata, and installation scripts. DNF operates by interacting with remote repositories, which are servers hosting package files and their associated metadata. The DNF tool uses the libsolv library for dependency resolution, which employs a SAT solver algorithm to find a consistent set of packages that satisfy all dependencies and avoid conflicts. This approach is more robust than the older YUM dependency resolver, which sometimes produced incomplete or incorrect solutions. The package metadata format is XML, and DNF downloads it from repositories, processes it, and caches it locally to speed up future operations. The core of DNF is written in Python and C, with a command-line interface that accepts subcommands such as install, remove, update, upgrade, downgrade, autoremove, list, search, provides, info, repoquery, and many more. Each subcommand can accept package names, package globs, file paths (for the provides function), or repository specifiers. The transaction system in DNF is designed to be atomic: before any actual changes to the system are made, DNF builds a complete transaction that includes download, checksum verification, dependency resolution, and conflict checking. If any step fails, the entire transaction is rolled back without making changes to the installed packages. DNF uses the RPM database as its source of truth for what is currently installed. It queries this database to determine available versions, file ownership, and dependency state. DNF also supports configuration in /etc/dnf/dnf.conf and repository definitions in /etc/yum.repos.d/. These files specify repository URLs, GPG key locations, proxy settings, and other options like fastestmirror which automatically selects the fastest repository mirror based on latency testing. DNF also integrates with Delta RPMs, which allow downloading only the changes between package versions instead of the whole package, saving bandwidth. The tool also supports strong authentication via GPG signatures, so packages can be verified to come from trusted sources before installation. DNF has a modularity feature that allows users to choose between different versions of software stacks, called modules, which are groups of packages that are shipped and updated together. This is particularly relevant for application streams in RHEL 8 and 9. DNF also supports history tracking, allowing users to undo or redo past transactions, which is extremely useful for troubleshooting. The command 'dnf history' lists past transactions, and 'dnf history undo [transaction-id]' can revert changes. The DNF automatic tool can be scheduled to run periodic updates via cron or systemd timers. In enterprise environments, DNF also works with subscription management tools like subscription-manager and product certificates. Understanding DNF and its ecosystem is fundamental for system administrators, DevOps engineers, and anyone managing Linux servers because it directly impacts system security, stability, and application availability.

DNF's command structure is intuitive but has advanced capabilities. For example, the 'dnf groupinstall' command installs predefined groups of related packages, like 'Development Tools' or 'Web Server'. The 'dnf repolist' command shows enabled repositories. The 'dnf clean all' command clears cached metadata to force a fresh download. DNF also handles multi-version package installations through the '--installroot' option for installing into chroot environments or building containers. The use of DNF over SSH for remote management is standard, and it can be integrated into configuration management tools like Ansible, Puppet, or Salt. For IT certification exams such as the Red Hat Certified System Administrator (RHCSA) or Red Hat Certified Engineer (RHCE), DNF is a critical skill. These exams require candidates to perform tasks like installing, updating, and removing packages, adding repositories, enabling modules, rolling back updates, and using GPG key verification. DNF also interacts with systemd for handling of package installation scripts and with the filesystem hierarchy standard. In terms of security, DNF's use of GPG signatures is mandatory by default in many distributions; failing to verify signatures can lead to installation of compromised packages. IT professionals should also be aware of 'dnf versionlock' which prevents specific packages from being updated, useful for maintaining compatibility with custom software. The command 'dnf list installed' lists all installed packages for auditing. The command 'dnf repoquery' provides detailed querying of repository packages. DNF's underlying SAT solver is also used by openSUSE's Zypper package manager, showcasing its influence beyond Red Hat systems.

## Real-life example

Imagine you are organizing a large community potluck dinner. Everyone is supposed to bring one dish, but many dishes need other items to be complete. For example, Sarah wants to bring tacos. Tacos need taco shells, meat, cheese, lettuce, and salsa. If Sarah just shows up with cooked meat and expects to serve tacos, there would be missing components. But with a potluck coordinator like DNF, the coordinator looks at Sarah's request and says, "I see you want to bring tacos. We need taco shells, cheese, lettuce, and salsa. I will also make sure that anyone else bringing dishes with cheese doesn't use the last piece without notifying you." The coordinator then contacts Bob, who already has taco shells from last week, and asks him to bring them. Bob is like an installed dependency. The coordinator also checks that the salsa doesn't conflict with anyone else's dish that might also need tomatoes. This mapping of needs to supplies is exactly what DNF does with software packages. A software package like a web server might require a specific version of a library, like OpenSSL, to handle encrypted connections. DNF sees that dependency and ensures that OpenSSL is installed first, or if it's already installed, checks for version compatibility. If a newer version of the web server requires a newer OpenSSL that might break another program on the computer, DNF will either block the installation or find a way to install both versions without conflict, much like the coordinator seating two dishes that both need tomatoes at separate tables so they don't run out.

Now consider the scenario where, after the potluck, some dishes are left over. The coordinator helps clean up by asking if anyone still needs the leftover taco shells. If no one does, they are thrown away to save space. DNF does this automatically with the 'autoremove' command, which removes packages that were installed as dependencies but are no longer needed by any remaining package. This keeps the system from becoming full of orphaned software. Another real-life parallel is with mobile apps. When you install a game on your phone, it often also installs additional framework files that the game needs to run. But when you delete the game, those framework files might remain, taking up space. DNF's behavior prevents that problem on Linux. So, for anyone who has ever struggled with leftover files on their computer or with installing software that had missing pieces, DNF is the solution that automates the process, ensuring completeness and cleanliness. This makes system management less error-prone and more efficient, which is precisely what is expected of IT professionals.

## Why it matters

DNF matters because it is the primary tool for software lifecycle management on Red Hat Enterprise Linux (RHEL), CentOS, Fedora, and many other RPM-based distributions. In any IT environment, keeping software up-to-date is critical for security, performance, and compliance. DNF provides a consistent, reliable, and scriptable way to perform these updates. For system administrators, DNF is not just a convenience but a necessity. Without it, administrators would have to manually download, compile, and install software packages, resolve dependencies by hand, and track updates individually. This would be error-prone, time-consuming, and impractical in enterprise environments with hundreds or thousands of servers. DNF enables centralized management of software through repositories, which can be internal mirrors that host approved software versions. This aligns with change management policies where only tested and approved packages are deployed to production systems. DNF also supports transactional updates, which means that if an update fails partway through, the system remains in its original state rather than becoming partially updated and potentially broken. This is crucial for high-availability systems where downtime must be minimized. DNF integrates with security advisory feeds, allowing administrators to quickly identify and apply security patches using commands like 'dnf update --security'.

DNF is a core competency for IT certification exams like RHCSA, RHCE, and Red Hat Certified Architect (RHCA). These exams explicitly test package management skills, including repository configuration, GPG key management, module streams, and rollback procedures. Mastering DNF gives candidates a direct advantage in both the exam and real-world job performance. It also influences other areas like configuration management, where tools like Ansible use DNF as a module for package management. Understanding DNF commands and their output helps in troubleshooting issues such as missing dependencies, corrupted RPM databases, or broken transactions. DNF's history command is a powerful troubleshooting tool that lets administrators see exactly what changed and when, making it easier to revert problematic updates. In DevOps and CI/CD pipelines, DNF can be used inside container images to install dependencies consistently. The tool also supports plugins that extend its functionality, such as 'dnf-plugin-spacewalk' for integration with Red Hat Satellite, or 'dnf-plugin versionlock' for pinning package versions. For any IT professional working with Linux, proficiency in DNF is a foundational skill that directly impacts system reliability, security, and operational efficiency. DNF matters because it is the gatekeeper of software on critical systems, and managing that gatekeeper well is essential for maintaining a healthy IT infrastructure.

## Why it matters in exams

DNF is heavily tested in Red Hat certification exams, particularly the Red Hat Certified System Administrator (EX200) and Red Hat Certified Engineer (EX300) exams. For the RHCSA, candidates must demonstrate the ability to install, update, and remove packages using DNF, as well as configure DNF repositories, both local and remote. The exam objectives explicitly list package management tasks, including using yum (the older tool) but modern exams have shifted to DNF commands. Frequently tested scenarios include: adding a new repository from a provided URL or local file, enabling and disabling repositories, installing packages from a specific repository, and verifying package integrity via GPG signatures. For the RHCE, more advanced tasks appear, such as using DNF modules to install specific application streams like PHP 7.4 or PostgreSQL 12, managing module profiles, and rolling back package transactions using 'dnf history undo'. The exam often requires candidates to troubleshoot package conflicts, such as when two packages require different versions of the same library, and to resolve those conflicts by choosing the correct packages or modifying repository priorities. Candidates may also need to use 'dnf repolist' to verify repository configuration matches a given specification.

Question types in these exams are primarily performance-based, meaning candidates must execute commands on a live system and achieve a specific outcome. For example, a question might state: "Server A has a system that must run a custom application that requires the ncurses-compat-libs package. Install this package and ensure it is not removed during future updates." This requires the candidate to not only install the package but also to use 'dnf versionlock' to pin it. Another common question type involves setting up a local repository from an ISO image or a mounted directory, which involves creating a .repo file in /etc/yum.repos.d/ and using 'createrepo' to build the metadata, then testing with 'dnf repolist'. Configuration mistakes like incorrect baseurl, missing file:// prefix, or wrong GPG key settings are classic traps. Also, candidates must understand the difference between 'dnf update' and 'dnf upgrade' (actually they are the same in modern DNF but historically different) and that 'dnf install' can accept a package name or a URL to an RPM file. The exam also tests 'dnf remove' versus 'dnf autoremove', where autoremove only removes unused dependencies. For RHCE-level tasks, module stream management is a key differentiator; candidates must know how to reset, enable, disable, and switch module streams. The exam environment typically resets after each question, so thorough understanding of commands is critical. DNF is tested in the context of system security, such as verifying GPG keys before installation and understanding that default settings enforce this. For IT certifications beyond Red Hat, such as Linux Professional Institute (LPI) or CompTIA Linux+, DNF concepts are covered as part of package management objectives, though those exams may also cover apt (Debian) and zypper (openSUSE). For LPI 101 and 102, candidates must know basic DNF commands and repository configuration. Overall, DNF is a high-yield topic for any Linux-related certification exam, and mastery of its commands and concepts is essential for success.

## How it appears in exam questions

In IT certification exams, DNF questions typically fall into three categories: configuration scenarios, troubleshooting scenarios, and command-based tasks. In configuration scenarios, the exam presents a scenario where a system needs to be set up with access to a specific software repository. For example, the question might read: "Configure the system to use the local repository located at /mnt/install/repo. Ensure packages can be installed from this repository and that GPG checking is enabled." The candidate must create a .repo file in /etc/yum.repos.d/ with the correct baseurl, gpgcheck=1, and gpgkey location. The exam environment will test if the repository is functional by asking the candidate to install a sample package. Mistakes such as using \"http://\" instead of \"file://\" or forgetting to run 'createrepo' on the repository if needed are common. Another common scenario is: "Your organization requires all servers to have the nikto package installed for security scanning. Use the default repositories to install it." This tests basic 'dnf install' command usage.

Troubleshooting questions often involve broken dependency resolution. For instance: "The system administrator reports that the httpd package cannot be installed due to a conflict with the httpd24 package. Resolve the conflict so that httpd can be installed." The candidate must identify that httpd24 provides a different version or set of libraries, and either remove httpd24 or use a module stream to select the version that is compatible. Another common trap: "After running 'dnf update', the system fails to boot. Identify what changed and revert the transaction." This requires using 'dnf history' to list recent transactions, then using 'dnf history undo' or 'dnf history rollback' to revert the problematic change. Candidates must also be able to use 'dnf list installed' and 'dnf repoquery --whatrequires' to identify dependent packages. A performance-based question might present a corrupted RPM database, requiring the candidate to rebuild it using 'rpm --rebuilddb' and then re-verify package integrity with 'dnf verify'.

Command-based tasks are straightforward but tricky because options must be exact. For example: "List all available packages from the AppStream repository that match the pattern 'python*' and display their summary." The correct command is 'dnf repoquery --repoid=AppStream --whatprovides python* --info' or simply 'dnf repoquery --repoid=AppStream python* --info'. The exam does not allow guesswork; command syntax must be precise. Another classic question: "Ensure that the kernel package is not accidentally updated to a newer version during routine updates." The candidate must use 'dnf versionlock add kernel' or add the package to /etc/dnf/plugins/versionlock.list. The exam may also test the '--nogpgcheck' option, but this is often a trap because security-conscious environments require GPG checking. The candidate should know that using --nogpgcheck is possible but not recommended for security reasons. Questions may ask to install a package from a specific URL, like 'dnf install https://example.com/package.rpm'. The candidate must understand that this downloads and installs the RPM directly, bypassing repository metadata, and may lead to unverified packages. Exam questions also test the difference between 'dnf remove' and 'dnf autoremove', where autoremove only removes unused dependencies. For example: "Remove the library libfoo and any other packages that were installed as dependencies of libfoo and are no longer required." The answer is 'dnf autoremove libfoo'. This requires understanding that autoremove is the safe way to clean up dependencies. Overall, exam questions are practical and require hands-on familiarity with DNF commands and their effects on the system.

## Example scenario

You are a junior system administrator for a small company that hosts its own customer database on a Linux server running CentOS Stream 8. The software development team has informed you that they need to install the 'golang' package to compile a new customer portal. However, the server is currently running an older version of a dependent library, 'glibc', which is required by the existing database application. You need to check whether installing golang will cause any conflicts. In a real exam, you would start by running 'dnf install golang' without actually confirming the installation. DNF would then analyze the dependency tree and report any issues. For this scenario, you simulate the transaction using the '--assumeno' flag, which shows what would happen without actually installing. You type: sudo dnf install golang --assumeno. The output shows that golang requires glibc >= 2.28, but the system has glibc 2.17. DNF flags an error: "Nothing provides glibc >= 2.28 needed by golang." This tells you that golang cannot be installed without upgrading glibc. But upgrading glibc might break the existing database software, which was compiled against the older glibc. So you need to find an alternative. You run 'dnf list --available golang*' to see if there is an older version of golang that works with the current glibc. Unfortunately, only one version is available in the default repos. You then check with 'dnf repoquery --whatrequires glibc' to see all packages depending on glibc. You see that the database application is listed. You then check the developer's documentation and find that the database software is available in a containerized version that doesn't depend on system libraries. You decide to use containers instead. In the exam, you would then successfully install the container runtime using 'dnf install podman' (which has no conflict with glibc) and download the golang container image using 'podman pull golang'. This scenario tests the ability to use DNF to diagnose and resolve dependency conflicts, use repoquery to investigate dependencies, and think of alternative solutions. It also highlights the importance of transactional safety, as DNF blocks the installation that would break the system. The scenario reinforces that DNF is not just a package installer but a tool for intelligent system management.

## Common mistakes

- **Mistake:** Running 'dnf update' without first checking the transaction with '--assumeno'.
  - Why it is wrong: Performing a full update without previewing can cause unexpected package removals or conflicts, potentially breaking running services.
  - Fix: Always use 'dnf update --assumeno' first to see what will change, then proceed with 'dnf update' if satisfied.
- **Mistake:** Using 'dnf remove' instead of 'dnf autoremove' to clean up unused dependencies.
  - Why it is wrong: 'dnf remove' only removes the specified package, leaving orphaned dependencies on the system that waste space and may cause future conflicts.
  - Fix: Use 'dnf autoremove' to remove the target package along with all packages that were pulled in as dependencies and are no longer needed.
- **Mistake:** Forgetting to disable a repository after using it for a specific installation, leaving it enabled for future updates.
  - Why it is wrong: An enabled repository could provide untested packages during routine updates, causing instability in a production environment.
  - Fix: Use '--enablerepo=' only for the specific install command, or set the repository's 'enabled=0' in the .repo file and enable it manually only when needed.
- **Mistake:** Assuming that 'dnf update' and 'dnf upgrade' are different commands performing different actions.
  - Why it is wrong: In modern DNF, both commands are identical. This confusion wastes time in exams and scripts.
  - Fix: Remember that both commands do the same thing. Check the man page or help output if in doubt, but they are synonyms.
- **Mistake:** Installing packages without verifying GPG signatures by habitually using '--nogpgcheck'.
  - Why it is wrong: Disabling GPG checking bypasses package authentication, exposing the system to potentially malicious or tampered software.
  - Fix: Ensure GPG keys are imported and set gpgcheck=1 in repo files. Use 'rpm --import' for keys and avoid --nogpgcheck in production.
- **Mistake:** Running 'dnf clean all' as a first troubleshooting step when package installation fails.
  - Why it is wrong: Cleaning caches removes locally stored metadata, forcing a fresh download of all repository data, which can be slow and is often unnecessary.
  - Fix: First check common issues like network connectivity, repository URLs, or GPG errors. Use 'dnf clean all' only if corruption is suspected.

## Exam trap

{"trap":"The question asks to install the 'php' package, but expects the candidate to realize that 'php' is available via the 'php:7.4' module stream, not as a standalone package name.","why_learners_choose_it":"Learners typically type 'sudo dnf install php' and get an error because the default repository has no package called 'php' without specifying the module.","how_to_avoid_it":"Before installing, run 'dnf module list php' to see available streams. Then enable the appropriate stream with 'dnf module enable php:7.4' and then install 'php' from within that module, or directly install using 'dnf module install php:7.4'."}

## Commonly confused with

- **dnf vs YUM:** YUM is the predecessor to DNF. DNF uses a more modern dependency resolver (libsolv) and has faster performance. The command syntax is very similar, but DNF has additional features like modularity and better history tracking. (Example: On Fedora 21, use 'yum install nano'; on Fedora 22+, use 'dnf install nano'.)
- **dnf vs APT:** APT is the package manager for Debian-based distributions (like Ubuntu), while DNF is for RPM-based distributions (like Fedora). The commands and package format are completely different. (Example: On Ubuntu, you use 'apt install curl'; on Fedora, you use 'dnf install curl'.)
- **dnf vs RPM:** RPM is a lower-level tool that installs individual .rpm files without dependency resolution. DNF builds on top of RPM and automatically handles dependencies and repositories. (Example: Use 'rpm -ivh package.rpm' to install a single RPM file ignoring dependencies; use 'dnf install ./package.rpm' to install with automatic dependency resolution.)
- **dnf vs Zypper:** Zypper is the package manager for openSUSE and SUSE Linux Enterprise. It also uses libsolv (like DNF) but has different command syntax and configuration files. (Example: On openSUSE, 'zypper install vim'; on Fedora, 'dnf install vim'.)

## Step-by-step breakdown

1. **Command Invocation** — The user types 'dnf install <package-name>' in the terminal. DNF reads configuration files at /etc/dnf/dnf.conf and /etc/yum.repos.d/*.repo to determine which repositories are enabled and their connection settings.
2. **Metadata Download and Verification** — DNF contacts each enabled repository and downloads the repomd.xml file, which contains metadata about the repository's packages, including checksums. DNF verifies the integrity of this metadata using GPG keys if configured. It then downloads other metadata files like primary.xml and filelists.xml.
3. **Dependency Resolution Using SAT Solver** — DNF feeds the package request along with the full dependency graph from the metadata into the libsolv SAT solver. The solver attempts to find a set of packages that satisfies all dependencies, conflicts, and obsoletes. If successful, it produces a transaction of packages to install, remove, or update.
4. **Transaction Check and Conflict Detection** — DNF performs a pre-transaction sanity check. It verifies that all required packages are available, that no packages in the transaction conflict with each other, and that disk space is sufficient. If any check fails, the transaction is aborted and DNF reports the error to the user.
5. **Package Download** — For each package in the transaction, DNF downloads the .rpm file from the repository. It verifies the checksum and GPG signature of each downloaded package. If Delta RPMs are enabled and available, DNF may download only the binary diff and reconstruct the new package locally to save bandwidth.
6. **Package Installation via RPM** — DNF calls the RPM tool to install or upgrade each package in the correct order based on dependencies. RPM executes pre-install and post-install scripts, runs file triggers, and updates the RPM database. DNF monitors this process and records the transaction in its history database.
7. **Post-Transaction Cleanup and History Logging** — After successful installation, DNF updates its local cache and records the transaction in /var/lib/dnf/history. If the 'clean_requirements_on_remove' option is set, DNF marks packages that were installed as dependencies. DNF then returns the user to the shell prompt.

## Practical mini-lesson

DNF is not just a command-line tool; it is an ecosystem that manages software lifecycle on RPM-based systems. Understanding its inner workings enables IT professionals to troubleshoot, automate, and secure their environments. The most common daily task is updating packages. In practice, you should never run 'dnf update' without previewing the changes. The command 'dnf check-update' lists available updates without applying them. Similarly, 'dnf update --assumeno' provides a full transaction preview. For production systems, it is standard to schedule updates using 'dnf-automatic' or a cron job that only applies security updates. You configure this in /etc/dnf/automatic.conf, setting upgrade_type = security. This ensures non-critical updates do not disrupt services. Another critical skill is resolving dependency conflicts. If you encounter an error like "Error: nothing provides libfoo.so.1 needed by myapp", you need to identify which repository provides that library. Use 'dnf provides libfoo.so.1' to find the package. Then ensure that repository is enabled. If the library is too new or old, you might need to enable a module stream that offers a compatible version. For example, default PHP modules may conflict if you need both PHP 7.2 and 7.4. You can use 'dnf module enable php:7.2' and 'dnf module enable php:7.4' but they cannot both be active at the same time. The solution is to either choose one version for the whole system or use containers to isolate applications. DNF also handles package groups. For instance, 'dnf groupinstall "Development Tools"' installs gcc, make, and other compilers. This is useful for setting up build environments quickly. Group information can be viewed with 'dnf group list' and 'dnf group info "Group Name"'.

Another practical aspect is repository management. As a professional, you often need to create custom repositories for internal software. You can do this by placing RPM files in a directory, running 'createrepo' to generate metadata, and then creating a .repo file pointing to that directory via file:// or http://. You must also sign your packages with a GPG key and import that key onto client systems using 'rpm --import'. For automation and configuration management, DNF commands can be used in Ansible playbooks via the 'dnf' module. For example, the Ansible task '- name: Install httpd dnf: name=httpd state=latest' will ensure the latest version is installed. DNF also supports transaction history rollback, which is a lifesaver in production. If an update breaks something, run 'dnf history list' to see transaction IDs, then 'dnf history undo <ID>' to revert. This does a reverse transaction, removing packages that were added and reinstalling packages that were removed. However, it is not always perfect if packages were manually changed afterward. The 'dnf history info <ID>' shows full details. Finally, security is paramount. Always verify GPG keys: 'rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}
'' lists imported keys. Ensure 'gpgcheck=1' in repository configurations. Also, disable unnecessary repositories by setting 'enabled=0' to minimize attack surface. Understanding DNF at this depth is what separates a competent technician from an expert system administrator.

## Memory tip

Think of DNF as the "Do Not Forget" manager: it never forgets dependencies, never forgets to clean up, and never forgets to verify signatures.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/dnf