You've probably used rpm -i with -v and -h more times than you can count. It's the bread and butter of package installation, right? But sometimes, the standard approach just doesn't cut it. When you hit those trickier scenarios, or just want to peek under the hood, RPM offers a surprising depth of options.
Getting More Insight with -vv
Ever wished you could see exactly what RPM is doing, step-by-step? That's where -vv comes in. It's like turning up the volume on RPM's internal monologue. You'll start seeing lines prefixed with 'D:', revealing everything from running pre-install scripts to setting file ownership and permissions. The "files test = 0" line is a good sign – it means the actual installation is about to happen. If that number were different, it would indicate a test run, which we'll get to.
This level of detail is usually reserved for the folks building RPM itself, and the output can change without warning. But for us mere mortals, it's an invaluable tool for understanding the installation process, especially when things go sideways. It shows you the pre-install script execution, the individual file installations, and finally, the post-install script.
The --test Option: A Dry Run for Safety
Before committing to an installation, especially in critical environments or when you're unsure, the --test option is your best friend. It performs all the checks RPM would normally do – dependency resolution, file conflicts, and so on – but stops short of actually touching your system. It's a virtual installation, a safe preview.
When the test passes, you'll see minimal output, which is a good thing! However, if there are problems, --test will reveal them clearly. Imagine trying to install an older version of RPM over a newer one; --test will dutifully report the file conflicts. Or, it might flag missing dependencies, like needing a specific version of another package. This is a lifesaver for scriptwriters too, as RPM returns a non-zero exit code when --test encounters issues, making automation much more robust.
--replacepkgs: When You Need to Start Fresh
What if a package is installed, but something's gone wrong? Maybe it's corrupted, or you just need to ensure a clean slate with the exact same version. That's where --replacepkgs shines. Normally, trying to install a package that's already there will result in an error. But with --replacepkgs, you can force RPM to overwrite the existing installation with a fresh copy of itself.
--replacefiles: Navigating File Ownership Conflicts
This is where things get a bit more nuanced. While --replacepkgs deals with replacing an entire package, --replacefiles is for those situations where a new package you're trying to install happens to contain files that are already owned by another installed package. It's a way to tell RPM, "Yes, I know these files are already claimed, but I want this new package to take them over." It's a powerful option, and like any powerful tool, it requires careful consideration to avoid unintended consequences.
