One of the advantages of Fedora is the huge amount of software available for it. Finding, installing, updating, and removing this software can be a daunting task, simply due to the amount of software available.
Fortunately, Fedora uses a software management system called RPM Package Manager or simply RPM (formerly RedHat Package Manager). RPM rolls all of the programs, scripts, documentation, configuration files, and data used by a piece of software into a single file called a package . The package also contains metadata describing the package, license, maintainers, and the packages upon which the package depends (for example, a KDE application will need other components of the KDE system to operate).
What RPM doesn't provide is dependency resolution : the ability to automatically resolve dependency issues. However, the yum system builds on RPM to provide this capability, automatically searching external repositories to find needed packages and install them automatically.
In this chapter, the sections Lab 5.1, "Querying the Package Management Database" and Lab 5.2, "Installing and Removing Software Using RPM" deal with individual package management from the command line. If you want to go directly to the simplest and most comprehensive way of managing software packages, skip to Lab 5.3, "Using Repositories."
The RPM package management database is an essential source of information about your system. The database is created when the system is installed and is updated whenever packages are added or removed.
As RPM packages are installed on your system, the metadata for those packages is stored in a database that can be queried. If you have a mystery file on your system and want to know where it came from, or want to know which version of a package is installed, or what a package does, an RPM query can answer your question in a few seconds.
The rpm program provides access to the RPM database. The -q option enables query mode.
The default query takes a package name and tells you whether it is installed and, if so, which version is installed:
$ rpm -q selmyscan
package selmyscan is not installed
$ rpm -q httpd
httpd-2.0.54-10.2
More advanced queries use two different sets of arguments: one to control which packages are reported in the output, and one to control what is reported about the selected packages.
Table 5-1 describes the most commonly used options for selecting packages.
Table 5-1. RPM query options for package selection
| Option | Description |
|---|---|
| -a | Selects all packages. |
| -f file | Selects the package that installed file. |
| -g pkggroup | Selects the packages that belong to pkggroup (such as Applications/Productivity). |
| -p pkgfile | Selects the uninstalled RPM package file pkgfile, which can be a local filename or an HTTP or FTP URI. Information is retrieved from the package file instead of from the RPM database. |
| --triggeredby package | Selects packages that have scripts that are triggered by the installation or removal of package. For example, a mail-client package may have a script that changes its configuration if the local mail server is changed from sendmail to postfix. |
| --whatprovides capability | Selects packages that provide a certain capability, such as the ability to run perl scripts. |
| --whatrequires capability | Selects packages that require a capability. |
| packagename | Selects a package with the given name. |
For example, to find out which package installed the file /usr/lib/libcdda_interface.so :
$ rpm -qf /usr/lib/libcdda_interface.so
cdparanoia-libs-alpha9.8-25
Or to find out which packages provide smtpdaemon (inbound mail server) capability:
$ rpm -q --whatprovides smtpdaemon
sendmail-8.13.4-2
postfix-2.2.2-2
Sometimes, though, you need more information than the name and version number of the packages selected. Table 5-2 lists the most common query output options.
Table 5-2. Query output options
| Option | Description |
|---|---|
| --changelog | Shows the package changelog, a list of changes to the various versions of the package (not necessarily to various versions of the software). |
| -c | Shows the configuration files included in the package. |
| -d | Shows the documentation files included in the package. |
| -l | Lists files included in the package. |
| --filesbypkg | Same as -l, except that the package name is printed in front of each file; useful when multiple packages are selected. |
| -i | Provides detailed information about the package (package description, license, group, origin, and so forth). |
| --provides | Lists the capabilities provided by the package. |
| --requires | Lists the capabilities required to successfully use the package. |
| --scripts | Displays pre- and post-installation scripts, and pre- and post-uninstallation (removal) scripts. |
| --triggers | Displays the trigger scripts in the package. Trigger scripts are invoked when another, related package is installed or removed. |
When output options and selection options are combined, rpm becomes a very powerful tool. For example, to see the description of the package that installed /etc/mail/access :
$ rpm -qif /etc/mail/access
Name : sendmail Relocations: (not relocatable)
Version : 8.13.4 Vendor: Red Hat, Inc.
Release : 2 Build Date: Fri 06 May 2005 08:35:13 AM EDT
Install Date: Mon 29 Aug 2005 12:46:19 AM EDT Build Host: decompose.build.redhat.com
Group : System Environment/Daemons Source RPM: sendmail-8.13.4-2.src.rpm
Size : 1332268 License: Sendmail
Signature : DSA/SHA1, Fri 20 May 2005 01:44:43 PM EDT, Key ID b44269d04f2a6fd2
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary : A widely used Mail Transport Agent (MTA).
Description :
The Sendmail program is a very widely used Mail Transport Agent (MTA).
MTAs send mail from one machine to another. Sendmail is not a client
program, which you use to read your email. Sendmail is a
behind-the-scenes program which actually moves your email over
networks or the Internet to where you want it to go.
If you ever need to reconfigure Sendmail, you will also need to have
the sendmail.cf package installed. If you need documentation on
Sendmail, you can install the sendmail-doc package.
To see all of the files installed by the package that installed /usr/lib/libcdda_interface.so :
$ rpm -qlf /usr/lib/libcdda_interface.so
/usr/lib/libcdda_interface.so
/usr/lib/libcdda_interface.so.0
/usr/lib/libcdda_interface.so.0.9.8
/usr/lib/libcdda_paranoia.so
/usr/lib/libcdda_paranoia.so.0
/usr/lib/libcdda_paranoia.so.0.9.8
Or to see those files along with the package name:
$ rpm -qf --filesbypkg /usr/lib/libcdda_interface.so
cdparanoia-libs /usr/lib/libcdda_interface.so
cdparanoia-libs /usr/lib/libcdda_interface.so.0
cdparanoia-libs /usr/lib/libcdda_interface.so.0.9.8
cdparanoia-libs /usr/lib/libcdda_paranoia.so
cdparanoia-libs /usr/lib/libcdda_paranoia.so.0
cdparanoia-libs /usr/lib/libcdda_paranoia.so.0.9.8
To see all of the other capabilities provided by the package that provides the capability perl :
$ rpm -q --whatprovides perl --provides
APItest.so
B.so
Base64.so
Byte.so
ByteLoader.so
...(Lines snipped)...
perl(warnings::register) = 1.00
re.so
scalar.so
shared.so
threads.so
via.so
perl = 3:5.8.6-15
To see the scripts that will be triggered by removing sendmail :
$ rpm -q --triggeredby sendmail --triggers
triggerpostun scriptlet (using /bin/sh) -- sendmail < 8.10.0
/sbin/chkconfig --add sendmail
triggerpostun scriptlet (using /bin/sh) -- sendmail < 8.11.6-11
/usr/sbin/alternatives --auto mta
To list the files in the uninstalled RPM package file a52dec-0.7.4-4.fr.i386.rpm :
$ rpm -qlp a52dec-0.7.4-4.fr.i386.rpm
/usr/bin/a52dec
/usr/bin/extract_a52
/usr/share/doc/a52dec-0.7.4
/usr/share/doc/a52dec-0.7.4/AUTHORS
/usr/share/doc/a52dec-0.7.4/COPYING
/usr/share/doc/a52dec-0.7.4/ChangeLog
/usr/share/doc/a52dec-0.7.4/NEWS
/usr/share/doc/a52dec-0.7.4/README
/usr/share/doc/a52dec-0.7.4/TODO
/usr/share/doc/a52dec-0.7.4/liba52.txt
/usr/share/man/man1/a52dec.1.gz
/usr/share/man/man1/extract_a52.1.gz
If that RPM were on a remote web server or FTP server, you could substitute the URI for the filename:
$ rpm -qlp \ ftp://ftp.ntua.gr/pub/video/videolan/testing/vlc-0.7.0-test1/rpm/rh9-fc1/rh9-fc1/vlc/a52dec-0.7.4-4.fr.i386.rpm
/usr/bin/a52dec
/usr/bin/extract_a52
...(Lines snipped)...
RPM packages are compressed archives of files with metadata. The archive is in cpio format, with gzip compression; the metadata is stored in a flexible, easily extensible format for forward- and (limited) backward-compatibility.
When a package is installed, the metadata is copied to the RPM database. If this were not done, it would be necessary to keep all of the original package files in storage to find out about installed packages, and queries would run very slowly because hundreds of files would have to be individually opened and searched.
The RPM database is stored in several files in /var/lib/rpm . These databases are in the indexed DBM/GDBM format, which is also used for other configuration databases such as /etc/aliases.db ; this indexed format permits high-speed searching.
The rpm2cpio command will convert an RPM package to a cpio archive:
$ rpm2cpio gnome-applet-gvid-0.3-1.i386.rpm > gnome-applet.cpio
You can then use cpio to examine or install the archive. Note that rpm2cpio removes the gzip compression on the archive contents, so the resulting file is larger than the original RPM file. If you want to extract a specific file from the archive, you can use the cpio command. However, this is not a good way to install the file, since none of the scripts and other install-time actions will be performed:
$ rpm2cpio gnome-applet-gvid-0.3-1.i386.rpm | cpio -idv
Use rpm with the -- rebuilddb option to recover from most forms of database corruption (this can take a while to run). You will need to run it as root :
# rpm --rebuilddb
Maximum RPM (an online book about the RPM systemsomewhat out of date but still useful), Chapter 5 : http://www.rpm.org/max-rpm-snapshot/
The RPM web site: http://www.rpm.org
The manpages for rpm and cpio
In addition to queries, rpm performs package installation, updating, and removal. As well as copying files to the correct locations (or deleting them), rpm checks file integrity, sets permissions, backs up configuration files, and executes scripts within the affected package and other packages that have asked to be notified of changes (trigger scripts). These scripts can in turn start or stop services, modify configuration files, or perform other operations.
rpm provides four options for installing, upgrading, and removing software:
-i package_file
Installs a package that is not currently installed.
-U package_file
Upgrades an existing package version, or installs the package if it is not currently installed.
-F package_file
Freshens an existing installation of the package by upgrading the version. If the package is not currently installed, it remains uninstalled.
-e package
Erases the installed package. Unlike the other options, -e requires a package name ( httpd ), not a package filename ( httpd-2.0.54-10.i386.rpm ).
All of these operations must be performed as the root user (unlike queries, which may be performed by anyone). This prevents unwanted software, such as viruses and worms, from being installed in the normal course of activities.
To perform a basic installation of a package, use the -i option and supply the name of a package file:
# rpm -i httpd-2.0.54-10.i386.rpm
To upgrade the package:
# rpm -U httpd-2.0.62-3.i386.rpm
In this case, the upgrade would succeed even if httpd package weren't already present on the system; it would be installed.
To remove the package:
# rpm -e httpd
Note that in this case, only the package name is given, not a package filename.
No additional arguments are needed if the installation or removal does not affect any other packages, but frequently a package to be installed will depend on other packages:
# rpm -i ogle-0.9.2-1.1.fr.i386.rpm
error: Failed dependencies:
libdvdread >= 0.9.4 is needed by ogle-0.9.2-1.1.fr.i386
libdvdread.so.3 is needed by ogle-0.9.2-1.1.fr.i386
libmad.so.0 is needed by ogle-0.9.2-1.1.fr.i386
Likewise, when removing a package, other packages can depend on that package:
# rpm -e httpd
error: Failed dependencies:
httpd-mmn = 20020903 is needed by (installed) mod_auth_kerb-5.0-6.i386
httpd-mmn = 20020903 is needed by (installed) mod_auth_mysql-2.6.1-4.i386
...(Lines snipped)...
httpd = 2.0.54-10.2 is needed by (installed) mod_ssl-2.0.54-10.2.i386
httpd is needed by (installed) squirrelmail-1.4.6-0.cvs20050812.1.fc4.noarch
The solution is to add or remove all of the needed packages at the same time ( \ indicates that the line is continued):
# rpm -i a52dec-0.7.4-4.fr.i386.rpm libdvdcss-1.2.8-2.fr.i386.rpm \ libdvdread-0.9.4-4.fr.i386.rpm libmad-0.15.0b-3.fr.i386.rpm \ ogle-0.9.2-1.1.fr.i386.rpm ogle_gui-0.9.2-1.1.fr.i386.rpm
However, each of the other package may have other dependencies, which is why repositories are so helpful (see Lab 5.3, "Using Repositories ").
Table 5-3 outlines the most common options used when installing or upgrading packages.
Table 5-3. rpm options for installing and upgrading
| Option | Description |
|---|---|
| --excludepath directory | Excludes files located in directory. |
| --excludedocs | Excludes documentation files. This will save some space and may be useful on a small system, particularly if another machine is available with the documentation installed. |
| --force | Enables rpm to overwrite files that are part of other packages, reinstall packages already installed, and downgrade instead of upgrade packages. |
| -v | Verbose; lists each package as it is processed. |
| -h | Displays hash marks (#) to show the progress of each operation. |
| --justdb | Updates the RPM database, but doesn't actually install any software. |
| --nodeps | Turns off checking for dependencies. Be careful using this option; the installed package will usually be unusable. |
| --noscripts | Prevents installation scripts in the package from running. |
| --notriggers | Prevents trigger scripts in other packages from running. |
| --oldpackage | Permits a downgrade instead of an upgrade. |
| --relocate olddir=newdir | Relocates files from one directory subtree to another. Useful if you want your binary files, datafiles, or documentation installed into an unusual location. Many Fedora packages are not relocatable. |
| --repackage | (Applies to update/freshen only). Repackages the files from the old version of the package so that the upgrade can be undone (rolled back). See Lab 5.4, "Rolling Back a Package Installation, Upgrade, or Removal." |
| --test | Checks for conflicts and potential problems, but does not make any actual changes to the system. |
This command installs httpd (Apache) without documentation, using a verbose display with hash marks to show progress:
# rpm -ivh --excludedocs httpd-2.0.54-10.i386.rpm
Preparing... ########################################### [100%]
1:httpd ########################################### [100%]
If you later decide that you want the documentation files after all, you can't simply reinstall httpd :
# rpm -ivh httpd-2.0.54-10.i386.rpm
Preparing... ########################################### [100%]
package httpd-2.0.54-10 is already installed
But if you add the --force option, the reinstallation will be successful:
# rpm -ivh --force httpd-2.0.54-10.i386.rpm
Preparing... ########################################### [100%]
1:httpd ########################################### [100%]
The httpd package normally places the DocumentRoot (start of the HTML document tree) in /var/www ; to change this to /usr/share/html , use the --relocate option:
# rpm -ivh --force --relocate /var/www=/usr/share/html/ httpd-2.0.54-10.i386.rpm
Preparing... ########################################### [100%]
1:httpd ########################################### [100%]
The change is recorded in the RPM database, so querying the database will show the actual, installed paths:
# rpm -ql httpd
/etc/httpd
/etc/httpd/conf
/etc/httpd/conf.d
/etc/httpd/conf.d/README
/etc/httpd/conf.d/welcome.conf
...(Many lines snipped)...
/usr/share/html/icons/world1.png
/usr/share/html/icons/world2.gif
/usr/share/html/icons/world2.png
Relocating files does not change configuration files, scripts, or programs that expect files to be located in particular locations. In the httpd example just shown, the Apache configuration files (/etc/httpd/conf/httpd.conf plus module-specific files in /etc/httpd/conf.d/*) must be edited by hand to reflect the new document root.
The options for erasing software are a subset of the options for installing and upgrading; the most useful options are listed in Table 5-4 .
Table 5-4. rpm package-removal (erase) options
| Option | Description |
|---|---|
| --allmatches | Erases all packages matching the name given (useful if more than one version is installed). |
| --nodeps | Proceeds with the package removal even if doing so will break some dependencies for other packages. |
| --noscripts | Prevents removal scripts in the package from running. |
| --notriggers | Prevents trigger scripts in other packages from running. |
| --repackage | Repackages the files being removed so that the removal can be undone (rolled back). See Lab 5.4, "Rolling Back a Package Installation, Upgrade, or Removal." |
| --test | Checks for conflicts and potential problems, but does not make any actual changes to the system. |
RPMs are named using the pattern:
name - version - packagerelease . arch .rpm
in which:
name
The name of the software in the package.
version
The software's version number.
packagerelease
The package version number; if one version of the software has been packaged a few times (for example, with different file locations, scripts, triggers, or sample data), this number is incremented while the software version number is left unchanged.
arch
The architecture for which the package is compiled ( i386 , x86-64 , or PPC ). For packages that are not compiled (such as Perl, PHP, or bash scripts) or packages that contain only data (such as a font set), noarch is used; for source packages, the architecture is set to src .
rpm goes through many steps when performing an installation or upgrade/freshen:
1. The viability of the operation requested is analyzed. rpm tests the available disk space, dependencies, installed packages, and package integrity to ensure that the operation can be successfully completed. If not, the user is informed and rpm aborts execution.
2. The RPM database is queried to see if any installation trigger scripts in other packages are triggered by the installation, and if so, they are executed.
3. The preinstallation script in the package is executed.
4. The package files are installed. Required directories are created, relocations are performed, and permissions and ownership are adjusted.
5. The postinstallation script in the package is executed.
6. If the operation being performed is not an upgrade or freshen, rpm exits because there isn't an older version of the package to uninstall.
7. The RPM database is queried to see if any uninstallation trigger scripts in other packages are triggered by the removal of the old package, and if so, they are executed.
8. The pre-uninstallation script in the package is executed.
9. If repackaging has been selected, the old package files and metadata are used to construct an RPM, which is placed in /var/spool/repackage .
10. The obsolete files from the old package are deleted.
11. The post-uninstallation script in the package is executed.
12. The RPM database is queried to see if any post-uninstallation trigger scripts in other packages are triggered by the removal of the old package, and if so, they are executed.
13. The RPM database is updated to reflect what was done during the transaction.
There are four opportunities for scripts to run. This permits configuration files to be backed up before new packages are installed, services to be stopped before upgrading and restarted after, and configuration data to be copied from the old to the new package. There are also three opportunities for trigger scripts to run.
Each RPM operation is called a transaction . All of the packages processed in one operation are called a transaction set ; this may include a large number of packages. For example, an update transaction could include dozens of packages processed at one time. In the RPM database, a transaction set identifier (TID) is used to tie together all of the packages processed in the same transaction set. The TID currently used is the time in seconds since the start of the 1970s (called a utime ).
It's possible, but it can create a lot of problems. The --force option is required, and it's probably best to relocate the second installation to avoid file conflicts:
# rpm -q httpd
httpd-2.0.54-10.2
# rpm -i --force httpd-2.0.54-10.i386.rpm \ --relocate /=/var/compare/httpd-old
# rpm -q httpd
httpd-2.0.54-10.2
httpd-2.0.54-10
This will install the old version of httpd into /var/compare/httpd-old so that you can compare that installation with the current one.
To remove the packages, you'll either need to specify the full package name including the software and package version numbers (e.g., httpd-2.0.54-10 instead of httpd ) to delete one specific version, or use the --allmatches option to remove all versions:
# rpm -e httpd
error: "httpd" specifies multiple packages
# rpm -e --allmatches httpd
Maximum RPM , Chapters 2 , 3 , and 4 : http://www.rpm.org/max-rpm-snapshot/ (somewhat out of date, but useful)
The manpage for rpm
RPM is a great package manager, but to really use packages efficiently, you'll need to use RPM along with a repository system so that your Fedora system can access remote libraries of software. Having access to the repository enables the automatic resolution of dependency issues, so that when you select a software package for installation, all required associated software is also installed automatically.
Fedora uses the yum repository system. The apt system was used in earlier versions of Fedora and is still available, but most of the community's attention has shifted to yum, primarily because it supports multiple architecturesuseful when running 32-bit software (such as a 32-bit browser, for compatibility with closed-source plug-ins) on a 64-bit system.
Using yum to install software is easy; just specify the install command and the package name you want installed as an argument:
# yum install abe
Setting up Install Process
Setting up repositories
updates-released 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 336 kB 00:01
updates-re: ################################################## 987/987
Added 24 new packages, deleted 43 old in 2.06 seconds
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for abe to pack into transaction set.
abe-1.0-5.i386.rpm 100% |=========================| 5.1 kB 00:00
---> Package abe.i386 0:1.0-5 set to be updated
--> Running transaction check
--> Processing Dependency: libSDL_mixer-1.2.so.0 for package: abe
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for SDL_mixer to pack into transaction set.
SDL_mixer-1.2.6-1.fc4.i38 100% |=========================| 6.9 kB 00:00
---> Package SDL_mixer.i386 0:1.2.6-1.fc4 set to be updated
--> Running transaction check
Dependencies Resolved
==========================================================================
Package Arch Version Repository Size
==========================================================================
Installing:
abe i386 1.0-5 extras 2.9 M
Installing for dependencies:
SDL_mixer i386 1.2.6-1.fc4 extras 84 k
Transaction Summary
==========================================================================
Install 2 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 2.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): SDL_mixer-1.2.6-1. 100% |=========================| 84 kB 00:03
(2/2): abe-1.0-5.i386.rpm 100% |=========================| 2.9 MB 02:16
Running Transaction Test
Notice that yum automatically determined that SDL_mixer was required, confirmed the installation of both packages with the user before installing, downloaded the software in RPM format, and then installed it.
From this output, you can also see that yum started off by updating its list of available packages in each repository and later downloaded the header files for each selected package. A header file contains a package's metadata but not the installation files and scripts (and is therefore much smaller); this lets yum determine dependencies and test for file conflicts without downloading the entire package.
To install a package file that is on the local computer (e.g., received in an email from a developer or on a CD) and still take advantage of the repositories to solve dependency problems, use yum 's localinstall command:
# yum localinstall /tmp/frodo-9.6.23-4-i386.rpm
Removing software is just as simple as installing it; use yum 's remove command:
# yum remove httpd
Setting up Remove Process
Resolving Dependencies
...(Lines snipped)...
Dependencies Resolved
==========================================================================
Package Arch Version Repository Size
==========================================================================
Removing:
httpd i386 2.0.54-10.2 installed 2.5 M
Removing for dependencies:
htdig-web i386 3:3.2.0b6-5 installed 1.1 M
httpd-devel i386 2.0.54-10 installed 466 k
httpd-devel i386 2.0.54-10.2 installed 466 k
httpd-manual i386 2.0.54-10.2 installed 7.5 M
...(Lines snipped)...
squirrelmail noarch 1.4.6-0.cvs20050812.1.fc4 installed 8.1 M
system-config-httpd noarch 5:1.3.2-2 installed 1.6 M
webalizer i386 2.01_10-28 installed 244 k
wordtrans-web i386 1.1pre13-10 installed 31 k
Transaction Summary
==========================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 39 Package(s)
Total download size: 0
Is this ok [y/N]: n
Exiting on user Command
Complete!
Here, the removal of httpd would cause dependency failures for 38 other packages, so yum offered to remove all 39 packages together. In this case, the user elected not to proceed, so yum exited.
yum can also update software:
# yum update
Setting up Update Process
Setting up repositories
...(Lines snipped)...
Transaction Summary
==========================================================================
Install 5 Package(s)
Update 19 Package(s)
Remove 0 Package(s)
Total download size: 27 M
Is this ok [y/N]: y
Downloading Packages:
(1/24): bind-utils-9.3.1- 100% |=========================| 146 kB 00:00
(2/24): esound-0.2.36-0.f 100% |=========================| 127 kB 00:00
...(Lines snipped)...
Running Transaction Test
Repackage : bind-utils ####################### [ 0/43]
Repackage : esound ####################### [ 0/43]
...(Lines snipped)...
Installing: GFS-kernel ####################### [22/43]
Updating : bind-libbind-devel ####################### [23/43]
Installed: GFS-kernel.i686 0:2.6.11.8-20050601.152643.FC4.17 cman-kernel.i686
...(Lines snipped)...
pam.i386 0:0.79-9.6 pam-devel.i386 0:0.79-9.6 sudo.i386 0:1.6.8p8-2.3
Complete!
For each of the currently installed packages, yum checks to see if a newer version exists in any of the repositories and queues the update of those packages plus the installation of any packages required for dependency resolution. After confirming the package set with the user, the packages are downloaded and the update/installation is performed through the RPM system.
To update one specific package (and dependencies), list the package name as an argument:
# yum update kernel
yum also offers a number of information and miscellaneous options; the most useful are shown in Table 5-5 . However, most of these operations are more easily performed using the graphical user interface (GUI).
Table 5-5. Information and miscellaneous commands for yum
| Option | Description |
|---|---|
| list | Lists available packages. |
| check-update | Verifies whether any updates are available. An exit code of 100 indicates that updates are ready for installation. |
| whatprovides capability | Displays the name of any packages that provide the listed capability, which may be an RPM-style capability name or a filename. |
| provides capability | |
| search keyword | Searches for a package with keyword in the description, summary, packager name, or package name metadata. The search is case-insensitive. |
| info package | Displays metadata about package (similar to rpm -qi). |
| deplist package | Displays the dependencies of package, including the names of the packages that will resolve those dependencies. |
| localinstall rpm_file | Installs or removes the package contained in the local rpm_file and, if necessary, resolves any dependencies using the repositories. |
| localupdate rpm_file | |
| -C | Runs the specified command from cache (doesn't contact each repository to check for updates). |
Fedora Core also provides graphical tools for using yum . When updates are available for any of the packages on your system, an update icon (which looks like a cardboard box) will appear in the upper GNOME panel. If you place your mouse cursor over this icon, a tool tip message will appear showing the number of available updates, as shown in the upper-right corner of Figure 5-1.
The yum-updatesd service must be running to make the update icon appear.
To install the available updates, right-click on the update icon and select Apply Updates (or select Applications→System Tools→Software Updater, or enter the command pup). You will be prompted for the root password, and then the window shown in Figure 5-1 will appear; click "Apply updates" to install the updates listed.
Figure 5-1. The package updater window and notification icon
Fedora Core also provides a tool for graphically installing and removing software, named Pirut (pronounced "pirate"). To start this program, select the menu option Applications→Add/Remove Software; you will be prompted for the root password. Pirut offers three main modes of operation, as shown in Figure 5-2; these modes are selected using the buttons on the left side of the window and permit you to search for a specific package (the top window in Figure 5-2), browse by package groups (middle window, along with the window that appears when you click on "Optional packages"), or scroll through a list of all packages (bottom window).
If the browse-package-groups window looks familiar, you have a good memory. The same display is used for software package customization during installation.
Select the checkbox in front of the packages that you wish to install, and deselect the checkbox of the packages that you wish to uninstall; then click Apply. After confirmation, the selected actions will be performed.
Figure 5-2. The three operating modes of Pirut, the Install/Remove Software tool
Fedora Extras also provides the Yumex tool, which provides an alternate graphical frontend to yum.
Fedora Core ships with configuration files for the six repositories listed in Table 5-6 . The three prerelease repositories are disabled by default, and the rest are enabled.
Table 5-6. Fedora Core repositories
| Repository | Enabled by default | Description |
|---|---|---|
| base | Y | Fedora Core base packages (same as CD/DVD) |
| development | N | Prerelease Fedora Core packages (also known as "Rawhide") |
| updates-released | Y | Updates to Fedora Core packages |
| updates-testing | N | Prerelease update packages |
| extras | Y | Add-on software for Fedora |
| extras-development | N | Prerelease add-on software |
The repositories are configured by files in /etc/yum.repos.d . Here is the content of the Fedora Extras file /etc/yum.repos.d/fedora-extras.repo :
[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/
mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc$releasever
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
After the section identifier [updates-released] , there are several name/value pairs, each on a separate line, joined with equal signs:
name
The repository name as it will be shown to the user. The variables $releasevar and $basearch are replaced with the distribution release ( 6 ) and the system architecture ( i386 , x86_64 , or ppc ).
baseurl
The master URL for the repository.
mirrorlist
The URL of a text file listing all of the mirrors (alternate servers that are loaded from the master server) for the repository. It is better to use a mirrorlist than a baseurl entry to avoid overloading the master server and to provide multiple servers for redundancy.
enabled
1 to enable this repository, or 0 to ignore this repository.
gpgcheck
1 to enable GPG verification of the origin of the RPM packages served by the repository, or 0 to disable GPG verification. GPG verification tests the package integrity and ensures that the package has not been tampered with (which helps to guard against Trojans and viruses).
gpgkey
URL of the GPG public key for GPG package verification. This is almost always a file:/// URL (the key is on the local system).
There are a number of repositories available in addition to the ones preconfigured in Fedora. The maintainer of the Unofficial Fedora FAQ (http://www.fedorafaq.org/) also maintains a list of available repositories. You can install configuration files for these repositories with this command:
# rpm -Uvh http://www.fedorafaq.org/yum
Rerunning this command periodically will update the repository list.
Although this command installs the repository files, most of them are disabled by default. This is because some repositories are not compatible.
The two main add-on repositories groups used in conjunction with the base, updates, and extra repositories are the Livna ( http://rpm.livna.org ) repository, and the RPMforge repositories, a group of repositories that have agreed to work together for compatibility ( http://rpmforge.net ). There have been compatibility issues between these two, so repositories from only one of them should be enabled.
The Livna repository is located outside of the United States and distributes packages that have license or patent issues that make them ineligible for inclusion in the Fedora or Fedora Extras repositories. This may include usage restrictions (such as personal use only) or U.S. patent encumbrances. Check the licenses carefully to ensure that you can legally use the software in your circumstances in your jurisdiction.
The FedoraFaq repository configuration files have livna enabled and the other repos disabled by default.
You can manually edit the files in /etc/yum.repos.d/ and change the lines that read:
enabled=0
to read:
enabled=1
RPM packages contain dependency information that indicates which capabilities are needed by the package and which capabilities are provided by the package. What they don't contain is information about which other packages provide or require those capabilities. Packages can't contain that information because the other packagesthe ones that provide and require capabilitieschange over time.
yum contains the logic to search repositories based on these capabilities. It can therefore resolve dependencies automatically.
There are three levels of information managed by yum : a list of packages available from the repositories, including capabilities provided by those packages; the headers for packages, which contain the metadata for those packages, including the capabilities required by those packages; and the packages themselves, which include both the metadata and the file archive. All of this information is stored in /var/cache/yum .
The first level of information, the list of available files, is updated automatically whenever yum (or one of the graphical tools) is started. The second level, headers, is retrieved when yum needs to determine dependencies. The actual packages are retrieved only after the decision to install or update the software has been confirmed.
The update icon is managed by the puplet monitor, which receives update information from the yum-updatesd services over the desktop communication bus (dbus).
The Livna repository provides RPM-packaged versions of the ATI and NVIDIA drivers. For the ATI drivers, install kmod-fglrx (or kmod-fglrx-smp for a multiprocessor/multicore kernel); for the NVIDIA drivers, install kmod-nvidia (or kmod-nvidia-smp ).
For example, to install the NVIDIA drivers on a single-core, single-processor system:
# yum install kmod-nvidia
Each vendor's video control tools will be installed into the application menus. During the installation, the appropriate changes will be made to the Drivers lines in the X server configuration file /etc/X11/xorg.conf , and those changes will automatically be undone if the proprietary drivers are removed.
Each proprietary video driver requires a kernel module, so you may need to wait until a day or two after a new kernel is released before upgrading to that kernel.
Software to play proprietary audio and video formats (such as MP3, WMA, and AVI) is available from the Livna repository. It is not included in Fedora Core because it does not meet the Fedora guidelines (either it is not open source, or it is patent-encumbered).
Once you have enabled the Livna repository, you can install a wide range of audio and video software and decoders (codecs) using the command:
# yum install '*mplayer*' '*xmms*' '*xine*'
To exclude packages from yum , edit /etc/yum.conf and add an exclude line. Here is an example (shown in bold); substitute globbing patterns (see Lab 4.3, "Managing Files ") that match the packages you wish to exclude:
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
retries=20
obsoletes=1
gpgcheck=1
exclude=*kernel* *xorg*
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
The yum project page: http://linux.duke.edu/projects/yum/
The manpages for pup , puplet , pirut , yum-updatesd , and yum-updatesd.conf
The yumex project page: http://linux.rasmil.dk/cms/modules/dokuwiki/doku.php?id=yumex:yumex
Repository pages for the RPMforge repositories ( http://rpmforge.net/ ) and the Livna repository ( http://rpm.livna.org/ )
Fedora project documentation on managing software with yum : http://fedora.redhat.com/docs/yum/
RPM has the ability to save datafiles before erasing them, permitting installations, updates, and removals to be undone through a rollback operation. Since it can take a substantial amount of space to save data necessary for a rollback, this feature is not enabled by defaultbut it's well worth sacrificing some disk space in most cases.
In order to enable rollbacks, it is necessary to enable repackaging during the upgrading and removal of software. This can be enabled using command options, but the options have to be used consistently, and it's easy to forget them. Therefore the best approach is to configure both rpm and yum to use repackaging all the time.
To configure rpm , create the file /etc/rpm/macros and place this line in it:
%_repackage_all_erasures 1
To configure yum , edit /etc/yum.conf and add the tsflags ( transaction set flags ) line shown in bold here:
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
retries=20
obsoletes=1
gpgcheck=1
exclude=*xorg* *xfree* *XFree* *kernel*
tsflags=repackage
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
The tsflags line may appear anywhere after the [main] tag.
Once you have set this up, any package removal or upgrade (which is actually an installation and a removal performed together) will create a backup of the old data.
You can then roll back to a particular point in time by performing an upgrade with rpm and specifying the --rollback option with the time you wish to revert to:
# rpm -Uhv --rollback '10 minutes ago'
Rollback packages (+1/-0) to Sat Oct 29 15:23:40 2005 (0x4363cc3c):
Preparing... ########################################### [100%]
1:abe ########################################### [ 50%]
Cleaning up repackaged packages:
Removing /var/spool/repackage/abe-1.0-5.i386.rpm:
Notice that the rollback installed one package and removed no packages (+1/-0) , and that the rollback data was deleted after the rollback.
The format for --rollback values is quite flexible; most reasonable dates and times are interpreted correctly. Here are some examples:
# rpm -Uhv --rollback 'last Monday'
# rpm -Uhv --rollback '2 hours ago'
# rpm -Uhv --rollback '10 Jan 2007 16:30'
# rpm -Uhv --rollback 'march 17'
# rpm -Uhv --rollback '9:00 am'
# rpm -Uhv --rollback '4:30 pm last Monday'
# rpm -Uhv --rollback 'yesterday'
When repackaging is enabled and RPM package updates or removals are performed, the metadata for the package to be removed is combined with the current state of the package's files to create a new RPM package. This is different from the original package used to install the software because it reflects any changes that were made to the package's files. Configuration changes, deleted files, high scores, changes in sample data, and script modifications are all included in the repackaged file. This permits the package to be restored in exactly the same form as it was when it was removed.
However, files that were not in the archive portion of the original RPM package are neither repackaged nor erasedso if you install a package such as MySQL and create files with it (databases, in the case of MySQL), those files will not be removed when MySQL is removed, and they won't be restored if the package removal is rolled back.
Repackaged files are in standard RPM format, with two exceptions: the transaction ID (date and time of the transaction in seconds since the start of 1970) is recorded in the RPM, and the signatures and hashes are usually invalid because the repackaged files are different from the original files (at least the modification time of the files has changed, and in many cases the contents of one or more files, as well).
Installing a package does not create a repackaged RPM because there are no files already on the system that need to be repackaged. However, the package installation is recorded in the RPM database, and that is enough information for rpm to roll back the transaction: it just erases the package.
Sorry, there are just too many variables to roll back a rollback! To prevent confusion rpm deletes repackaged files once they have been used for rollback.
rpm 's --test option is very useful for this:
# rpm -Uhv --test --rollback "1 minute ago"
Rollback packages (+1/-0) to Sat Oct 29 22:47:27 2005 (0x4364343f):
Preparing... ########################################### [100%]
Cleaning up repackaged packages:
Removing /var/spool/repackage/abe-1.0-5.i386.rpm:
From the output, you can see that this rollback will result in one package being reinstalled and no packages being removed ( +1/-0 ). The package being reinstalled can be identified from the clean-up line: it's abe .
To proceed with the rollback, execute the command again without the --test option:
# rpm -Uhv --rollback "1 minute ago"
Repackaged files are stored in /var/spool/repackage . The total amount of disk space used is displayed by this command:
# du -sh /var/spool/repackage
15M /var/spool/repackage
If you are certain that you won't need to perform a rollback, you can delete these files to free up some disk space:
# rm -rf /var/spool/repackage
The repackage repository can grow to be fairly large. If you want to store it on another mounted disk, you can configure its directory by adding this line to /etc/rpm/macros :
_repackage_dir /bigdisk/repackage
This will use /bigdisk/repackage for future repackaging.
However, I prefer to use a symbolic link (see Lab 4.3, "Managing Files "), so that when I look in the default location I'll know where the files have been moved:
# mv /var/spool/repackage /bigdisk/repackage
# ln -s /bigdisk/repackage /var/spool/repackage
# ls -la /var/spool/repackage
lrwxrwxrwx 1 root root 18 Oct 31 14:47 /var/spool/repackage -> /bigdisk/repackage
The manpage for rpm (which covers the --repackage option but not --rollback )
The Linux Journal article "Transactions and Rollback with RPM": http://www.linuxjournal.com/article/7034
The manpage for cvs ; see the date format for -D for information on the date/time formats accepted by rpm 's --rollback option
One of the main reasons that packages are updated is to correct newly discovered security vulnerabilities. It's important to keep a system up-to-date so that these security vulnerabilities are eliminated as soon as fixes are made available.
Automating system updates makes this easy. Fedora is configured to perform updates automatically; all you need to do is turn this feature on.
Before turning on automatic updates, it's important to verify that yum is configured with the right options:
1. Repackaging should be enabled (see Lab 5.4, "Rolling Back a Package Installation, Upgrade, or Removal ") so that you can recover from a bad update. Make sure you have plenty of disk space for the repackage repository!
2. Ensure that yum is enabled only for the repositories that you wish to automatically update (see Lab 5.3, "Using Repositories ").
3. Exclude any packages that you do not wish to update automatically. In particular, think carefully about whether you want the kernel to be updated without your knowledge; such a change won't take effect until the next time the system boots, but changing the kernel can cause some software or services to fail until kernel modules are updated to match the new kernel.
Once you have yum configured the way you want, configure yum-updatesd to automatically apply updates. The configuration file /etc/yum-updatesd.conf initially looks like this:
[main]
# how often to check for new updates (in seconds)
run_interval = 3600
# how often to allow checking on request (in seconds)
updaterefresh = 600
# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus
# automatically install updates
do_update = no
# automatically download updates
do_download = no
# automatically download deps of updates
do_download_deps = no
Change the do_update line to enable the automatic installation of updates:
do_update = yes
Reload the yum-updatesd configuration to activate your changes, either though the services GUI tool or by entering this command:
# service yum-updatesd reload
Stopping yum-updatesd: [ OK ]
Starting yum-updatesd: [ OK ]
Don't change the emit_via option, or puplet will not work.
The yum-updatesd service polls your configured repositories at regular intervals to determine if updates are available for any of your installed packages. By altering the configuration file, you instruct yum-updatesd to install the updated packages that it finds (effectively performing a yum -y update at regular intervals).
By enabling the do_download and do_download_deps options, you can configure yum-updatesd to download available updates and related dependencies without installing them. This enables you to review the list of updates using Pup and then install selected updates without further download delay.
To set this up, configure /etc/yum/yum-updatesd.conf with these options:
# automatically install updates
do_update = no
# automatically download updates
do_download = yes
# automatically download deps of updates
do_download_deps = yes
The yum-updateonboot package can be used to update a machine whenever it is turned on. This ensures that security patches are automatically applied before the system is used. yum-updateonboot can be activated in addition to the automatic 4 a.m. update.
You can install and configure yum-updateonboot with these commands:
# yum install yum-updateonboot
Setting up Install Process
...(Lines snipped)...
=====================================================================
Package Arch Version Repository Size
=====================================================================
Installing:
yum-updateonboot noarch 0.3.1-1.fc4 extras 5.1 k
Transaction Summary
=====================================================================
Install 1 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 5.1 k
Is this ok [y/N]: y
...(Lines snipped)...
Installed: yum-updateonboot.noarch 0:0.3.1-1.fc4
Complete!
# chkconfig --add yum-updateonboot
# chkconfig --level 2345 yum-updateonboot on
You can configure yum-updateonboot to reboot the system if any of the updates involve the kernel. Edit /etc/sysconfig/yum-updateonboot and activate the line highlighted here by removing the pound sign ( # ) at the start of the line:
# IF any of these rpms are updated, the yum-updateonboot init script will
# reboot immediately after the yum update. To keep yum-updateonboot from
# rebooting the system, comment this line out.
REBOOT_RPMS="kernel kernel-smp"
# A list of groups that should be updated at boot. For each group mentioned
# yum-updateonboot will call 'yum -y groupupdate' Since group names tend to
# have spaces in them, used a semi-colon to separate the group names
#GROUPLIST="My Group;MyOtherGroup;Some_Group;My Group 4"
The yum home page: http://linux.duke.edu/projects/yum/
The yum-updateonboot README file: /usr/share/doc/yum-updateonboot-0.3.1/README (install yum-updateonboot first)
Although there are thousands of packages available in RPM format ready to be installed on a Fedora system, there is a lot of open source software ( http://opensource.org ) that hasn't been packaged into RPMs. This software can be compiled and installed directly from the source files.
Most open source software follows a certain set of conventionsone that the community has adopted as a de facto standard:
The software is packaged in compressed tar format ( .tar.gz or .tgz ).
A configure script is provided, which analyzes the system (by trying to compile many tiny programs and attempting to locate certain programs and files). After this analysis, a Makefile is produced.
The Makefile contains the logic to build and to install the package.
Basic documentation, including pointers and licensing information, is contained in files with uppercase names such as README , INSTALL , TODO , and LICENSE .
To install software distributed this way:
1. Obtain the compressed tar file (or tarball ) containing the source. You can use a browser to find and download open source software from sites such as http://sourceforge.net .
2. Unpack the tarball:
3. $ tar xvzf xmorph_20040717.tar.gz
4. xmorph-current/
5. xmorph-current/Makefile.in
6. xmorph-current/gtkmorph/
7. xmorph-current/gtkmorph/ChangeLog
8. xmorph-current/gtkmorph/Makefile.in
9. xmorph-current/gtkmorph/README
10. xmorph-current/gtkmorph/Makefile.am
11. ...(Lines snipped)...
12.
13. If the file is compressed with bzip2 (usually indicated by a filename that ends in .tar.bz , .tar.bz2 , .tbz , .tb2 , or .tbz2 ), use the j option instead of z to decompress:
14. $ tar xvjf xmorph_20040717.tar.bz2
Most tarballs will unpack into their own directory, but some badly packaged ones may not, and unpacking them will leave dozens of files in your current directory. Use tar's t option instead of the x to see the table of contents before unpacking:
$ tar tvzf xmorph_20040717.tar.gz
1. Change to the new directory:
2. $ cd xmorph-current
3. Review the notes that are provided with the software (such as the README and INSTALL files).
4. If there is a script named ./configure , run it:
5. $ ./configure
6. checking for a BSD-compatible install... /usr/bin/install -c
7. checking whether build environment is sane... yes
8. checking for gawk... gawk
9. ...(Lines snipped)...
10. The Makefile will build morph.
11. The Makefile will build xmorph.
12. The Makefile will build gtkmorph.
13. configure: creating ./config.status
14. config.status: creating m4/Makefile
15. config.status: creating po/Makefile.in
16. config.status: creating Makefile
17. config.status: creating doc/Makefile
18. config.status: creating libmorph/Makefile
19. config.status: creating morph/Makefile
20. config.status: creating xmorph/Makefile
21. config.status: creating gtkmorph/Makefile
22. config.status: creating glade1/Makefile
23. config.status: creating glade2/Makefile
24. config.status: creating tkmorph/Makefile
25. config.status: creating plyview/Makefile
26. config.status: creating config.h
27. config.status: executing depfiles commands
28. config.status: executing default-1 commands
29. config.status: creating po/POTFILES
30. config.status: creating po/Makefile
31. Use make to build the software using the Makefile :
32. $ make
33. make all-recursive
34. make[1]: Entering directory \Q/tmp/xmorph-current'
35. Making all in m4
36. ...(Lines snipped)...
37. if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. \
38. -g -O2 -Wall -DREAL=double -DRGBA_MESH_WARP -g -O2 -Wall -MT \
39. my_malloc.lo -MD -MP -MF ".deps/my_malloc.Tpo" \
40. -c -o my_malloc.lo \Qtest -f 'my_malloc.c' || echo './'\Qmy_malloc.c; \
41. then mv -f ".deps/my_malloc.Tpo" ".deps/my_malloc.Plo"; \
42. else rm -f ".deps/my_malloc.Tpo"; exit 1; \
43. fi
44. ...(Lines snipped)...
45. make[2]: Leaving directory \Q/tmp/xmorph-current'
46. make[1]: Leaving directory \Q/tmp/xmorph-current'
If you have a multiprocessor or multicore system, use make -j3, assuming it's not also a multiuser machine and you don't mind two cores/CPUs being utilized at 100 percent.
1. If make was successful, use make install to install the software:
2. # make install
3. Making install in m4
4. make[1]: Entering directory \Q/tmp/xmorph-current/m4'
5. make[2]: Entering directory \Q/tmp/xmorph-current/m4'
6. ...(Lines snipped)...
7. mkdir -p -- /usr/local/share/xmorph/pixmaps
8. cd example; for i in * ;\
9. do /usr/bin/install -c -d /usr/local/share/xmorph/example/$i ;\
10. for j in $i/* ;\
11. do /usr/bin/install -c -m 644 $j \
12. /usr/local/share/xmorph/example/$i; done;\
13. done
14. make[2]: Leaving directory \Q/tmp/xmorph-current'
15. make[1]: Leaving directory \Q/tmp/xmorph-current'
At this point, the software should be ready to use.
A tarball is an archive of files created by tar (the tape archiving program) and usually compressed using gzip . By convention, source code tarballs are named <package-version> .tgz and all of the files extract into a directory named <package-version> ; for example, fen-10.4.tgz would extract into the directory ./fen-10.4/ .
Since the 1980s, source packages have often contained a script named configure ; most recent open source projects use versions of this script generated by a tool called GNU autoconf . The configure script adapts the compilation process for various systems; for example, some Unix systems have multiple C compilers installed, or different versions of libraries such as malloc , so configure determines what is available and the compiler options that will be needed to compile the software on the current system.
The output of configure usually includes one or more Makefile s and sometimes a C header file. The Makefile s contain the commands necessary to build the software, as well as dependency information; make uses this file to perform the least amount of work necessary to build the required output files. Another section of the Makefile contains the commands necessary to install the softwareperforming operations such as copying files and creating directoriesand this section is used when the make install command is executed.
The disadvantage of installing software from source is that you lose the benefits of the RPM database. It can be hard to uninstall the software, and you have no record of which version was installed, when it was installed, what dependencies it requires or satisfies, and which files are associated with it. Any updates must be performed manually, and any conflicts that other updates may cause will not be known in advance.
These packages may still need processing. For example, the manpages may be in a raw format that needs preprocessing, and scripts may need to be adjusted according to where the language interpreter is installed. In most cases, these packages will have a Makefile , just like a compiled package.
The Makefile may be sufficiently simple or generic that it will work on a wide range of systems, or you may need to adjust it manually. Look for a file named INSTALL or README for information on the steps you need to perform to compile and install the software.
The manpages and info pages for autoconf and make
While it's fairly easy to install software from source, it's not much more work to build an RPM package, especially if the original source code is well-written and in a traditional tarball. The extra work will make it much easier to track, update, and remove the software installed on your system.
In order to build an RPM, you need to have the original source tarball plus a spec file , which provides most of the metadata for the RPM package and controls how the RPM is builtbut before you build any packages, you should customize your RPM environment.
RPMs are digitally signed by the packager. Although this is an optional step, it indicates that the package is from a trusted source and provides a way of verifying that no one has tampered with it.
RPM signatures are generated using GNU Privacy Guard ( gpg or gnupg ), which can also be used to sign or encrypt email messages. If you have not created a gpg key, this is a great time to do so:
$ gpg --gen-key
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: directory \Q/home/chris/.gnupg' created
gpg: new configuration file \Q/home/chris/.gnupg/gpg.conf' created
gpg: WARNING: options in \Q/home/chris/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring \Q/home/chris/.gnupg/secring.gpg' created
gpg: keyring \Q/home/chris/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name:
Chris Tyler
Email address:
Comment:
ENTER
You selected this USER-ID:
"Chris Tyler <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
Enter passphrase:
seeecret
Repeat passphrase:
seeecret
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
+++++++++++++++++++++++++++++++++++++++++++++.+++++++++++++++++++++++++.+++
+++++++.+++++++++++++++.+++++++++++++++++++++++++>++++++++++...............
............................<+++++...>+++++........................<.+++++.
++....+++++
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
+++++++++++++++++++++++++.+++++..+++++++++++++++..++++++++++.+++++.++++++++
++++++++++++..+++++.+++++++++++++++.++++++++++..+++++++++++++++...+++++.+++
.+++++>.+++++...............+++++^^^^
gpg: /home/chris/.gnupg/trustdb.gpg: trustdb created
gpg: key B2B16060 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/B2B16060 2005-11-07
Key fingerprint = 6283 3FDE 833B D21A 209A 75D2 369E E05E B2B1 6060
uid Chris Tyler <[email protected]>
sub 2048g/2931B80E 2005-11-07
Your gpg keys will be created and stored in ~/.gnupg : the private key in ~/.gnupg/secring.gpg , and the public key in ~/.gnupg/pubring.gpg .
The second step in setting up your RPM environment is to create an ~/.rpmmacros file. This file contains your personal information and controls where RPMs will be built.
Here is a version of the ~/.rpmmacros file that is fully automatic; it will discover all of the information it needs from your account configuration and gpg setup. Type it into a text editor such as vi and save it as .rpmmacros in your home directory:
#
# ~/.rpmmacros file
#
# This gets all necessary information from environment variables and
# system utilities. The first e-mail address on your gnupg keyring
# should be your own.
#
%packager %(finger -l $LOGNAME|sed -n "s/.*Name: //p")
%distribution Fedora Core %(tr -dc [0-9] </etc/fedora-release)
# The vendor here is the same as the packager. Use a company or
# organization if appropriate.
%vendor %{packager}
%_home %(echo $HOME)
%_topdir %{_home}/rpm
%_tmppath %{_topdir}/tmp
%_builddir %{_tmppath}
%_rpmtopdir %{_topdir}/%{name}
%_sourcedir %{_rpmtopdir}
%_specdir %{_rpmtopdir}
%_rpmdir %{_topdir}/RPMS
%_srcrpmdir %{_topdir}/RPMS
%_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
%_signature gpg
%_gpg_path %{_home}/.gnupg
%_gpgbin /usr/bin/gpg
%_gpg_name %(gpg --list-keys|sed -n "s/^uid *//p"|head -1)
You can also create this file by manually filling in the values you wish to use:
#
# ~/.rpmmacros file
#
# This gets all necessary information from environment variables and
# system utilities. The first e-mail address on your gnupg keyring
# should be your own.
#
%packager Chris Tyler
%distribution Fedora Core 6
# Use an organization or company in the next line if applicable
%vendor Chris Tyler
%_home /home/chris
%_topdir /home/chris/rpm
%_tmppath /home/chris/rpm/tmp
%_builddir /home/chris/rpm/tmp
%_rpmtopdir /home/chris/rpm/%{name}
%_sourcedir %{_rpmtopdir}
%_specdir %{_rpmtopdir}
%_rpmdir /home/chris/rpm/RPMS
%_srcrpmdir /home/chris/rpm/RPMS
%_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
%_signature gpg
%_gpg_path /home/chris/.gnupg
%_gpgbin /usr/bin/gpg
%_gpg_name Chris Tyler <[email protected]>
To test that this file has been saved in the correct location and is being correctly interpreted by rpm , execute rpm --eval followed by the name of one of the macros:
$ rpm --eval "%_gpg_name"
Chris Tyler <[email protected]>
$ rpm --eval "%_srcrpmdir"
/home/chris/rpm/RPMS
Both versions of this file use the directory ~/rpm to hold packages being built. Within this directory, there will be:
A directory for each package being built, named after that package.
A directory named tmp , for temporary files created during the building process.
A directory named RPMS , to hold the final RPM packages.
You'll need to create these directories:
$ mkdir -p ~/rpm/RPMS ~/rpm/tmp
The fedora-rpmdevtools package provides the fedora-buildrpmtree command, which prepares a suitable directory structure within your home directory and creates a very basic .rpmmacros file. If you use this command, your RPMs will be built within the directory ~/rpmbuild.
The RPM building process is controlled by a spec file . Creating a good spec file is both a science and an art.
To start, create a new directory within ~/rpm to hold your source tarball and the spec file. In this example, I'm going to package up the game Critical Mass (also called critter ), available from http://sourceforge.net/projects/criticalmass . I'll name the directory after the package:
$ mkdir ~/rpm/ CriticalMass
I'll place the source tarball CriticalMass-1.0.0.tar.bz2 in this directory. The spec file will also be named after the package: CriticalMass.spec .
The first part of any spec file is called the preamble and contains the fields, or tags, outlined in Table 5-7 . Each tag is placed on a line by itself, followed by a colon and the value for that tag.
Table 5-7. Basic preamble tags in a spec file
| Tag | Description |
|---|---|
| Name | Name of the package. |
| Version | Version of the software in the package (software version). |
| Release | Release number of the package (package version). |
| Group | The application group to which the software belongs. See /usr/share/doc/rpm-4.4.2/GROUPS for a list of possible values. |
| URL | The software's home page on the Web. |
| License | The license used for the software (such as GPL or Mozilla). |
| Summary | A one-line summary of the package description. |
| Requires | Capabilities needed by the software in order to be successfully installed. Many requirements are automatically determined, so this line is often not needed. Also include in this tag any special capabilities required by install and uninstall scripts (or triggers). If a package name is given as an argument, a version number can be provided, and a comparison can be given (such as gcc >= 4.0 or sendmail = 8.13.4). |
| BuildRequires | Capabilities needed by the software in order to be successfully built, but not needed simply to install the RPM. For example, the gcc C compiler may be required to build the RPM package, but not to install it once it has been built. |
| Provides | Capabilities provided by the package. Like Requires, most of the Provides will be determined automatically. |
| BuildRoot | Specifies where the package should be installed during the package-building process. Many packages use %{_tmppath}/%{name}-root, which will create a package-specific directory within ~/rpm/tmp. It is strongly recommended that you do not use /. |
This is the initial information for the Critical Mass spec file:
Name: CriticalMass
Version: 1.0.0
Release: 1
Group: Amusements/Games
Summary: An arcade-style shoot-em-up game.
License: GPL
Source0: CriticalMass-1.0.0.tar.bz2
URL: http://sourceforge.net/projects/criticalmass
BuildRoot: %{_tmppath}/%{name}-root
One more tag must be defined %description but this tag does not take the name:value form. Instead, a description of the package follows on the lines after the tag:
%description
CriticalMass is an old-style arcade-style shoot-em-up game with modern graphics and sound.
The description text will be automatically wrapped and formatted to fit available space when it is displayed. To include preformatted text, leave a space at the start of each preformatted line.
After this initial information are seven sections, each identified by a section name:
%prep
Commands used to prepare the package for building.
%build
Commands used to build the package from the source (such as make ).
%install
Commands to install the software (such as make install ).
%check
Commands to test whether the software built correctly ( make test ). Optional; many packages do not include this section.
%clean
Commands to remove temporary files after a build.
%files
A list of the files that are to be included in the package.
%changelog
A history of package versions.
The %prep section might include all of the commands that would normally be used to prepare the package:
%prep
tar xvjf CriticalMass-1.0.0.tar.bz2
cd CriticalMass-1.0.0
However, since most open source packages use some simple variation of the same steps, Fedora's standard RPM setup includes a macro script to do this work for you. It's named %setup ; to use it, specify it as the only step in the %prep section of the spec file:
%prep
%setup
Similarly, the %build stage can use the predefined %configure macro to run ./configure before make is run:
%build
%configure
make %{_smp_mflags}
The %{_smp_mflags} macro, used as an argument to make , will contain the options required to configure the build process for a symmetric multiprocessor system with multiple CPUs if the package is being built on an SMP system. (For many applications, this will make no difference).
The %install section installs the filesnot into the final destination directories, but into the appropriate directories under the BuildRoot . In this case, since we've defined the BuildRoot as ~rpm/tmp/CriticalMass-root/ , files that would normally be installed into /usr/bin will be installed into ~rpm/tmp/CriticalMass-root/usr/bin .
There are two advantages to placing the files into the BuildRoot instead of the final file location: the Fedora system you're using won't get messed up, and since the only files that should be in the BuildRoot are those installed by this package, you can check to see that you can account for all of them.
The %install section often consists of an rm command to clear out the BuildRoot , followed by the %makeinstall macro to run make install with the appropriate options to install into BuildRoot instead of the root directory (most, but not all, modern open source packages will respect these options). The whole %install section looks like this:
%install
rm -rf %{buildroot}
%makeinstall
If you leave out the %check section (which is optional), the next section is %clean commands to clean up the BuildRoot . This is usually the same rm command that was used in the %install section:
%clean
rm -rf %{buildroot}
At this point, the whole spec file looks like this:
Name: CriticalMass
Version: 1.0.0
Release: 1
Group: Amusements/Games
Summary: An arcade-style shoot-em-up game.
License: GPL
Source0: CriticalMass-1.0.0.tar.bz2
URL: http://sourceforge.net/projects/criticalmass
BuildRoot: %{_tmppath}/%{name}-root
%description
CriticalMass is an old-style arcade-style shoot-em-up game with
modern graphics and sound.
%prep
%setup
%build
%configure
make %{_smp_mflags}
%install
rm -rf %{buildroot}
%makeinstall
%clean
rm -rf %{buildroot}
This file is saved in ~/rpm/CriticalMass/CriticalMass.spec . Note that the %prep , %build , %install , and %clean sections are pretty generic and could be used with many different packages.
The next section required is a list of files to be included in the package. The easy way to prepare this list is to have rpmbuild the RPM package-building toolbuild the package and install it into the BuildRoot , and then see what's there:
$ cd ~/rpm/ CriticalMass
$ ls
CriticalMass-1.0.0.tar.bz2 CriticalMass.spec
$ rpmbuild -bi CriticalMass.spec
Executing(%prep): /bin/sh -e /home/chris/rpm/tmp/rpm-tmp.54511
+ umask 022
+ cd /home/chris/rpm/tmp
+ LANG=C
...(Lines snipped)...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/chris/rpm/tmp/CriticalMass-root
error: Installed (but unpackaged) file(s) found:
/usr/bin/Packer
/usr/bin/critter
/usr/share/Critical_Mass/lg-criti.xm
/usr/share/Critical_Mass/resource.dat
/usr/share/man/man6/critter.6.gz
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/bin/Packer
/usr/bin/critter
/usr/share/Critical_Mass/lg-criti.xm
/usr/share/Critical_Mass/resource.dat
/usr/share/man/man6/critter.6.gz
If your build fails because you need additional software, you must find that software and add it to a BuildRequires line in the spec file.
The -bi argument to rpmbuild instructs it to build up to the end of the %install stage. You can see that rpmbuild has detected files in BuildRoot that are not included in the package. To see the actual contents of the BuildRoot , you can change to the ~/rpm/CriticalMass directory and look around:
$ cd ~/rpm/tmp/ CriticalMass -root
$ find
.
./usr
./usr/bin
./usr/bin/Packer
./usr/bin/critter
./usr/lib
./usr/lib/debug
./usr/lib/debug/usr
./usr/lib/debug/usr/bin
./usr/lib/debug/usr/bin/critter.debug
./usr/lib/debug/usr/bin/Packer.debug
./usr/share
./usr/share/man
./usr/share/man/man6
./usr/share/man/man6/critter.6.gz
./usr/share/Critical_Mass
./usr/share/Critical_Mass/resource.dat
./usr/share/Critical_Mass/lg-criti.xm
./usr/src
./usr/src/debug
The find command recursively lists all of the files found in the current directory.
From this list of files, you can build the %files section of the spec file. You can safely ignore the files in /usr/lib/debug and /usr/src since the RPM system will package these up into a separate debug RPM package automatically.
Among these files, there are some binaries:
./usr/bin/Packer
./usr/bin/critter
There is also a manpage:
./usr/share/man/man6/critter.6.gz
plus a data directory and some datafiles:
./usr/share/Critical_Mass
./usr/share/Critical_Mass/resource.dat
./usr/share/Critical_Mass/lg-criti.xm
The /usr/share/CriticalMass directory belongs to the package and should be removed when the package is removed. To configure this, you must list only the directory in the %files section of the spec file; the contents of the directory will automatically be included.
Other directories, such as /usr/bin and /usr/share/man/man6 , also contain files belonging to other packages, so those directories must not be included in the %files list; only the individual files in those directories should be included.
Because the RPM package is being built by a regular useryou or meand our accounts may not exist on the target machine, you must reassign the ownership (and possibly the permissions) of the files using the %defattr directive. %defattr accepts four arguments: the default permission for files, the owner, the group, and the default permission for directories. Use a hyphen for permissions to signify that the existing file permissions should be left untouched:
%defattr(-, root, root, -)
To set specific attributes for a specific file, use %attr with three arguments (permission, user, group):
%defattr(0511, root, nogroup) foofile
In addition to files in the BuildRoot , you should also identify files in the top-level directory of the tarball that should be included in the file as documentation; this is done using the %doc directive. When the package is installed, these files will be placed in /usr/share/doc/ <packagename-version> . Good candidates for documentation files include README , TODO , BUGS , INSTALL , COPYING , and any other notes the program author has provided. In the case of the CriticalMass software, only the files COPYING and TODO fit into this category:
%doc COPYING TODO
In a similar way, the %config directive specifies configuration files that are included in the RPM:
%config /etc/master.conf
%config(noreplace) /etc/master.conf
When an RPM update is performed, a file marked as %config is replaced with the new version, but the old version is saved as <filename>.rpmsave . Files marked as %config(noreplace) are not replaced; the new version of the config file is instead installed as <filename>.rpmnew .
In the case of CriticalMass, there are no configuration files installed by the RPM.
The whole %files section looks like this:
%files
%doc COPYING TODO
./usr/bin/Packer
./usr/bin/critter
./usr/share/man/man6/critter.6.gz
./usr/share/Critical_Mass
You can simplify this a bit by using ambiguous pathnames and macros:
%files
%doc COPYING TODO
%{_bindir}/*
%{_datadir}/Critical_Mass
%{_mandir}/man?/*
Finally, the %changelog section contains entries describing the changes that have been made to the RPM spec file (and, if desired, to the underlying software as well). The entries are placed in reverse chronological ordernewest firstand each entry takes the form:
* WWW MMM DD YYYY email version
- point form note
- another point
with the meaning:
WWW MMM DD YYYY
The date, such as Sat Jan 1 2006 .
email
The name and email address of the person who made the change, such as Chris Tyler <[email protected]>
version
The version number in which the change was made (optional).
For example:
%changelog
* Mon Nov 7 2005 Chris Tyler <[email protected]> 1.0.0-2
- Improved summary
* Sat Nov 5 2005 Chris Tyler <[email protected]>
- Initial RPM package.
Putting all of this together, the final spec file looks like this (note that I've incremented the release number to be consistent with the information in the %changelog section):
Name: CriticalMass
Version: 1.0.0
Release: 2
Group: Amusements/Games
Summary: An arcade-style shoot-em-up game.
License: GPL
Source0: CriticalMass-1.0.0.tar.bz2
URL: http://sourceforge.net/projects/criticalmass
BuildRoot: %{_tmppath}/%{name}-root
%description
CriticalMass is an old-style arcade-style shoot-em-up game with modern graphics and sound.
%prep
%setup -q
%build
%configure
make %{_smp_mflags}
%install
rm -rf %{buildroot}
%makeinstall
%clean
rm -rf %{buildroot}
%files
%defattr(-, root, root)
%doc COPYING TODO
%{_bindir}/*
%{_datadir}/Critical_Mass
%{_mandir}/man?/*
%changelog
* Mon Nov 7 2005 Chris Tyler <[email protected]> 1.0.0-2
- Improved summary
* Sat Nov 5 2005 Chris Tyler <[email protected]>
- Initial RPM package.
To build the final RPM package, use buildrpm with the -ba option (build all):
$ cd ~/rpm/ CriticalMass
$ rpmbuild -ba CriticalMass.spec
Executing(%prep): /bin/sh -e /home/chris/rpm/tmp/rpm-tmp.61308
+ umask 022
+ cd /home/chris/rpm/tmp
+ LANG=C
+ export LANG
...(Lines snipped)...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/chris/rpm/tmp/CriticalMass-root
Wrote: /home/chris/rpm/RPMS/CriticalMass-1.0.0-2.src.rpm
Wrote: /home/chris/rpm/RPMS/CriticalMass-1.0.0-2.i386.rpm
Wrote: /home/chris/rpm/RPMS/CriticalMass-debuginfo-1.0.0-2.i386.rpm
Executing(%clean): /bin/sh -e /home/chris/rpm/tmp/rpm-tmp.76425
+ umask 022
+ cd /home/chris/rpm/tmp
+ cd CriticalMass-1.0.0
+ rm -rf /home/chris/rpm/tmp/CriticalMass-root
+ exit 0
You'll find that rpmbuild created three RPM packages and placed them in ~/rpm/RPMS/ :
CriticalMass-1.0.0-2.i386.rpm
The binary RPM, ready to be installed and used.
CriticalMass-debuginfo-1.0.0-2.i386.rpm
Debugging info (from the /usr/lib/debug directory mentioned earlier). This package is rarely used, except by developers.
CriticalMass-1.0.0-2.src.rpm
A source RPM, which contains the source tarball and spec file. You can use this source RPM to easily generate a new binary RPM for a different type of system (see Lab 5.8, "Rebuilding an RPM Package for a Different Architecture ").
The binary RPM the most useful package, if you just want to play the gamecan be installed like any other RPM package:
# rpm -i CriticalMass-1.0.0-2.i386.rpm
You can also query it like any other package:
# rpm -qi CriticalMass
Name : CriticalMass Relocations: (not relocatable)
Version : 1.0.0 Vendor: Chris Tyler
Release : 2 Build Date: Mon 07 Nov 2005 11:59:11 PM EST
Install Date: Tue 08 Nov 2005 12:07:00 AM EST Build Host:bluesky.fedorabook.com
Group : Amusements/Games Source RPM: CriticalMass-1.0.0-2.src.rpm
Size : 4474014 License: GPL
Signature : (none)
Packager : Chris Tyler
URL : http://sourceforge.net/projects/criticalmass
Summary : An arcade-style shoot-em-up game.
Description :
CriticalMass is an old-style arcade-style shoot-em-up game with
modern graphics and sound.
# rpm -ql CriticalMass
/usr/bin/Packer
/usr/bin/critter
/usr/share/Critical_Mass
/usr/share/Critical_Mass/lg-criti.xm
/usr/share/Critical_Mass/resource.dat
/usr/share/doc/CriticalMass-1.0.0
/usr/share/doc/CriticalMass-1.0.0/COPYING
/usr/share/doc/CriticalMass-1.0.0/TODO
/usr/share/man/man6/critter.6.gz
And, of course, you can remove it easily:
# rpm -e CriticalMass
When you are certain that your RPM package is in good shape, you can digitally sign it:
$ rpm --addsign CriticalMass-1.0.0-2.i386.rpm
Enter pass phrase:
seeecret
Pass phrase is good.
CriticalMass-1.0.0-2.i386.rpm:
The default macro definitions for the RPM system are merged from several files when either rpm or rpmbuild starts:
/usr/lib/rpm/macros
Standard definitions distributed with the RPM software.
/etc/rpm/macros
Site-specific macros. Definitions that are local to your system and that should apply to all users should be placed here.
~/.rpmmacros
Per-user configuration information.
rpmbuild uses the spec file to create a script. This script contains an expansion of all of the macros (such as %configure and %makeinstall ) used in the spec file and is executed to prepare the RPM for packaging. (If rpmbuild is aborted or encounters a serious error, you will find the script in ~/rpm/tmp/ ). This script, in turn, references scripts found in /usr/lib/rpm to perform some of the processing involved in building a package.
When packages are built by the root user, the default RPM directories are used:
/usr/src/redhat/ BUILD
Temporary build files
/usr/src/redhat/ RPMS
Binary and debug RPMs that have been built
/usr/src/redhat/ SOURCES
Source tarballs (as well as patches, RPM icons, and related files)
/usr/src/redhat/ SPECS
Spec files
/usr/src/redhat/ SRPMS
Source RPMs that have been built
Since these directories are writable only by root , and it is not recommended that RPMs be built by the root user, it's best to use a set of directories within your home directory.
To create an entry in the menu, you will need to create a .desktop file in /usr/share/applications and (ideally) an icon in /usr/share/icons .
In the case of Critical Mass, there is an icon available in the top level of the tarball, so it can be fairly easily copied over to /usr/share/icons in the %install section of the spec file:
mkdir -p %{buildroot}%{_datadir}/icons
install -m 744 critter.png %{buildroot}%{_datadir}/icons/critter.png
Creating the .desktop file is almost as easy. Here are the contents of a .desktop file for Critical Mass:
mkdir -p %{buildroot}%{_datadir}/applications
echo "[Desktop Entry]
Name=Critical Mass
Comment=Shoot-em-up Game
Categories=Application;Game
Encoding=UTF-8
Exec=critter
Icon=critter.png
StartupNotify=true
Terminal=False
Type=Application" > %{buildroot}%{_datadir}/applications/CriticalMass.desktop
The .desktop file identifies all of the information necessary to create an additional entry in the desktop menu (whether KDE or GNOME):
Name
The name of the menu entry
Comment
The comment displayed as a tool tip message if you hover over the menu entry with the mouse pointer
Categories
The menu categories under which this entry will appear
Encoding
The character encoding used for this entry
Exec
The name of the command to be executed when this menu entry is selected
Icon
The name of the icon file
StartupNotify
Whether this icon supports the xdg startup notification protocol , which is used to manage a visual indication that the application is in the process of starting up
Terminal
Whether the application should be run in an terminal window (for nongraphical programs)
Type
Indicates that the program is a standalone application
The extended %install section looks like this:
%install
rm -rf %{buildroot}
%makeinstall
mkdir -p %{buildroot}%{_datadir}/icons
install -m 744 critter.png %{buildroot}%{_datadir}/icons/critter.png
mkdir -p %{buildroot}%{_datadir}/applications
echo "[Desktop Entry]
Name= Critical Mass
Comment= Shoot-em-up Game
Categories=Application; Game
Encoding=UTF-8
Exec =critter
Icon =critter.png
StartupNotify= true
Terminal= False
Type=Application" > %{buildroot}%{_datadir}/applications/CriticalMass.desktop
It is also necessary to modify the %files section to include the icon and .desktop file:
%files
%defattr(-, root, root)
%doc COPYING TODO
%{_bindir}/*
%{_datadir}/Critical_Mass
%{_mandir}/man?/*
%{_datadir}/applications/*
%{_datadir}/icons/*
This can be done by specifying a %pre , %post , %preun , or %postun section. The difference between these sections is in when they designate the script to run: before installation ( %pre ), after installation ( %post ), before removal ( %preun ), or after removal ( %postun ).
As a simple example, if your script contains shared object libraries ( .so files), you should run ldconfig after installation and after removal:
%post
/sbin/ldconfig
%postun
/bin/ldconfig
In this case, you should add a Requires tag to the preamble:
Requires: /sbin/ldconfig
A package icon can be included; graphical installation tools can pick up this icon and display it instead of a generic package icon. Place the icon in the same directory as the tarball, and create an Icon tag in the preamble:
Icon: CriticalMass.xpm
The icon should be in XPM format. You can use convert to make an XPM file from a file in another format:
$ convert critter.png critter.xpm
This is an excellent way to learn about writing advanced spec files. You don't even need root privileges to open and view the files!
After downloading the source RPM for a package ( .src.rpm file), install it in the normal way:
$ rpm -ivh ImageMagick-6.2.2.0-2.src.rpm
1:ImageMagick ########################################### [100%]
The files will be installed into ~/rpm/ name in this case, ~/rpm/ImageMagick :
$ ls ~/rpm/ ImageMagick
ImageMagick-5.5.6-mask.patch
ImageMagick-6.2.0-compress.patch
ImageMagick-6.2.1-fixed.patch
ImageMagick-6.2.1-hp2xx.patch
ImageMagick-6.2.1-local_doc.patch
ImageMagick-6.2.1-pkgconfig.patch
ImageMagick-6.2.2-0.tar.bz2
ImageMagick.spec
magick_small.png
The Fedora RPM guide: http://fedora.redhat.com/docs/drafts/rpm-guide-en/ (that's a draft version; the final version is expected to be posted at http://fedora.redhat.com/docs/rpm-guide-en/ )
Maximum RPM : http://www.rpm.org/max-rpm-snapshot/
The Fight , an RPM guide by Matthias Saou: http://freshrpms.net/docs/fight/
IBM DeveloperWorks article on creating RPM packages: http://www-128.ibm.com/developerworks/library/l-rpm1/
Sometimes you'll find an RPM has been prepared that would be perfect for your systemexcept that the RPM was built for a machine of a different architecture. This can be frustrating, but if you can obtain the source RPM, it's a fairly simple matter to make a binary RPM that is tuned to your system.
Assuming that you have set up your ~/.rpmmacros file (see Lab 5.7, "Making Your Own RPM Packages "), simply obtain a source RPM file, and then execute rpmbuild with the --rebuild option:
$ rpmbuild --rebuild
$ rpmbuild --rebuild ImageMagick*.src.rpm
Installing ImageMagick-6.2.2.0-2.src.rpm
Executing(%prep): /bin/sh -e /home/chris/rpm/tmp/rpm-tmp.32955
+ umask 022
+ cd /home/chris/rpm/tmp
...(Lines snipped)...
Executing(--clean): /bin/sh -e /home/chris/rpm/tmp/rpm-tmp.88067
+ umask 022
+ cd /home/chris/rpm/tmp
+ rm -rf ImageMagick-6.2.2
+ exit 0
The new RPM packages will be found in ~/rpm/RPMS/ .
When rebuilding a package, rpmbuild performs the equivalent of a source package installation ( rpm -i ), followed by a build-all ( rpmbuild -ba ), and then deletes the source files.
rpmbuild 's --rebuild option is useful only for a direct rebuild without any changes. If you need to edit the spec file, install the source RPM, edit the spec file, and then build the RPM packages normally (see Lab 5.7, "Making Your Own RPM Packages ").
The manpage for rpmbuild