RPM
From GarrettHoneycutt
Contents |
RPM
Commands
Show RPM keys
rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
Reinstall a package
#!/bin/bash # # 2009 - Garrett Honeycutt - code@garretthoneycutt.com # # Released under GPLv2 # # Purpose: to remove an rpm and reinstall via yum /usr/bin/sudo /bin/rpm -e --justdb --nodeps $1 /usr/bin/sudo /usr/bin/yum -y install $1 exit 0
List all installed rpm's
$ rpm -qaList information about a package
$ rpm -qi pkgname$ rpm -qi facter Name : facter Relocations: (not relocatable) Version : 1.5.2 Vendor: Fedora Project Release : 1.fc10 Build Date: Tue 09 Sep 2008 11:44:22 PM PDT Install Date: Mon 29 Dec 2008 04:05:06 PM PST Build Host: x86-2.fedora.phx.redhat.com Group : System Environment/Base Source RPM: facter-1.5.2-1.fc10.src.rpm Size : 105591 License: GPLv2+ Signature : DSA/SHA1, Tue 28 Oct 2008 11:10:11 AM PDT, Key ID bf226fcc4ebfc273 Packager : Fedora Project URL : http://reductivelabs.com/projects/facter Summary : Ruby module for collecting simple facts about a host operating system Description : Ruby module for collecting simple facts about a host Operating system. Some of the facts are preconfigured, such as the hostname and the operating system. Additional facts can be added through simple Ruby scripts
List files in a package
$ rpm -ql pkgname$ rpm -ql bc /usr/bin/bc /usr/bin/dc /usr/share/doc/bc-1.06 /usr/share/doc/bc-1.06/AUTHORS /usr/share/doc/bc-1.06/COPYING /usr/share/doc/bc-1.06/COPYING.LIB /usr/share/doc/bc-1.06/Examples /usr/share/doc/bc-1.06/Examples/ckbook.b /usr/share/doc/bc-1.06/Examples/pi.b /usr/share/doc/bc-1.06/Examples/primes.b /usr/share/doc/bc-1.06/Examples/twins.b /usr/share/doc/bc-1.06/FAQ /usr/share/doc/bc-1.06/NEWS /usr/share/doc/bc-1.06/README /usr/share/info/bc.info.gz /usr/share/info/dc.info.gz /usr/share/man/man1/bc.1.gz /usr/share/man/man1/dc.1.gz
List signatures
$ rpm --checksig pkgname$ rpm --checksig cft-0.2.2-1.x86_64.rpm cft-0.2.2-1.x86_64.rpm: (sha1) dsa sha1 md5 gpg OK cobbler-0.8.3-1.noarch.rpm: sha1 md5 OK
Signing packages
--addsign will add your gpg sign
$ rpm --addsign pkgname.rpm--resign will wipe the gpg sign and add yours
$ rpm --resign pkgname.rpmBuilding RPM's
RPM Packaging is fairly straightforward, and the basics are easy to learn. However, the flexibility that RPM allows can also lead to bad habits and packages that are difficult to maintain. This document is intended to show you where to find best practices documentation that you can use to make great RPMs.
The basic recipe
Building your RPM requires three basic components:
- A .tar.bz2, .tar.gz, or .zip of the files you want to package.
- A .spec file to define how the package is built.
- Use the RPMSpecTemplate to get yourself started.
- Any unified diffs that you will be using to patch the project.
- *IMPORTANT:* If you're customizing an upstream package, always use patches. Don't edit the package directly. This will allow you to easily upgrade the upstream files when it's time to update your package.
Build Environment Prerequisites
Your build environment will typically need a few basic packages for building an RPM. Make sure these are installed before building your package:
- rpm-build
- cpio
- core-utils
- patch
- Any packages that you specify as BuildRequires
External Resources
- Creating a Package How-To - read this if you've never created a package before.
- Fedora Packaging Guidelines - this is an excellent reference. A must-read.
- RPM Guide - A more current RPM book
- Maximum RPM book - Outdated and obsolete. Occasionally useful.
Helpful Tools
- rpmlint - A handy script for checking your spec files for common errors.
- */usr/lib/rpm/macros* - The file containing pre-defined macros used in spec files. These are macros for many common utilities, such as cp, mv, mkdir, or sed. For portability reasons, it's generally better to use the macro, than to call an explicit location on the filesystem. Read through this text file to get familiar with them.
- mock - Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot. Mock is one of the underlying tools used by Koji