29.7 Creating a Local Repository with createrepo

Right, so you’ve decided to become a package hoarder. I get it. Maybe you’ve got a fleet of air-gapped servers that can’t phone home to the mothership (the internet), or perhaps you’ve meticulously curated a set of packages that you don’t want yum or dnf second-guessing from some remote repo. Whatever your reason, creating a local repository is the way to go. And the tool for the job is createrepo_c (the modern, C-based successor to the old Python createrepo). It’s the thing that takes a directory full of .rpm files and makes them intelligible to your package manager. It does this by generating the all-important repodata directory, which is basically a set of XML files (primary, filelists, others) that act as a database cataloging every package in your directory—their dependencies, their files, everything. Without this, yum and dnf will look at your pile of RPMs and shrug. They need that metadata to do their job.

29.6 EPEL and Third-Party Repos: copr, rpmfusion

Right, so you’ve mastered the core dnf commands and you’re feeling pretty good about installing anything the main Fedora repos throw at you. Welcome to the warm-up. The real world of Linux software is a sprawling, chaotic bazaar, and a huge amount of it isn’t packaged by the distro maintainers. Maybe you need a proprietary graphics driver, a media codec that’s tangled in patent law, or the latest version of some niche developer tool. That’s where the concept of third-party repositories comes in, and it’s a game-changer. Think of them as official, curated, but externally maintained app stores that seamlessly plug into your system’s dnf machinery.

29.5 /etc/yum.repos.d: Repository Configuration Files

Alright, let’s get our hands dirty. If rpm is the engine that installs individual packages, then the repositories defined in /etc/yum.repos.d/ are the entire global supply chain that feeds it. This directory is the brains of the operation for yum and dnf, telling them where to find software, how to trust it, and what to care about. Ignore this, and you’re just hammering away with a blunt rpm tool; master it, and you unlock the entire curated universe of software for your distribution.

29.4 dnf history: Undoing and Redoing Transactions

Right, so you’ve just done a dnf upgrade and 200 packages flew by. Your terminal looks like the opening crawl of Star Wars. Now, what if, five minutes from now, you realize that this shiny new version of glibc has decided it no longer wants to be friends with your mission-critical, proprietary application that was built when Bill Clinton was in office? You panic. You consider calling in sick. Don’t. This is why dnf history exists. It’s your giant, glowing undo button for the entire universe of RPM packages. It’s not just a log; it’s a time machine, and I’m going to show you how to drive it.

29.3 dnf install, remove, update, search, and info

Right, so you’ve graduated from the stone tools of rpm and the venerable-but-aging yum. Welcome to dnf, the modern package manager. It stands for ‘Dandified Yum’, which is both the best and worst name in open source. It’s essentially yum but with a better dependency resolver, better performance, and a much saner API. It’s what you should be using on any modern Fedora, RHEL, or CentOS system. Let’s get you up to speed.

29.2 yum vs dnf: The Transition and Feature Differences

Alright, let’s talk about the great YUM-to-DNF shift. You remember YUM, right? The Yellowdog Updater, Modified. It was the workhorse of package management on RHEL, CentOS, and Fedora for over a decade. It got the job done, but let’s be honest: by the end, it was a bit like your favorite old couch—comfortable and familiar, but sagging in places, patched with duct tape, and occasionally smelling a bit funky. Its API was a mess, its performance was… leisurely, and its dependency resolution, while mostly correct, wasn’t exactly a marvel of algorithmic efficiency.

29.1 rpm: Installing, Querying, and Verifying .rpm Packages

Alright, let’s get our hands dirty with rpm. Forget the fancy, high-level package managers for a second. This is the foundation. rpm is the grumpy, meticulous, and brutally efficient librarian who handles the actual books (packages) on the shelves. yum and dnf are the friendly librarians who talk to you, figure out what you need, and then go bother the grumpy one to actually do the work. To really understand what’s going on, you need to talk directly to the grump.

— joke —

...