SEARCH
TOOLBOX
LANGUAGES
RPM

RPM

From GarrettHoneycutt

Jump to: navigation, search

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 -qa

List 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

First you need ~/.rpmmacros setup

%_gpg_name Your Name
%_signature gpg

add

--addsign will add your gpg sign

$ rpm --addsign pkgname.rpm

resign

--resign will wipe the gpg sign and add yours

$ rpm --resign pkgname.rpm

Building 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.
  • 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

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