Previous Page
Next Page

5.3. Using Repositories

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.

5.3.1. How Do I Do That?

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.

5.3.1.1. Using yum from the command line

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
OptionDescription
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
provides capability
                              

Displays the name of any packages that provide the listed capability, which may be an RPM-style capability name or a filename.
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
localupdate rpm_file
                              

Installs or removes the package contained in the local rpm_file and, if necessary, resolves any dependencies using the repositories.
-C

Runs the specified command from cache (doesn't contact each repository to check for updates).


5.3.1.2. Using yum with a GUI

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 ApplicationsSystem ToolsSoftware 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 ApplicationsAdd/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.


5.3.1.3. Adding repositories

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
RepositoryEnabled by defaultDescription
base YFedora Core base packages (same as CD/DVD)
development NPrerelease Fedora Core packages (also known as "Rawhide")
updates-released YUpdates to Fedora Core packages
updates-testing NPrerelease update packages
extras YAdd-on software for Fedora
extras-development NPrerelease 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
               

5.3.2. How Does It Work?

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).

5.3.3. What About...

5.3.3.1. ...installing proprietary video drivers?

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.


5.3.3.2. ...installing software to handle proprietary multimedia formats?

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*' 
               

5.3.3.3. ...excluding packages from management by yum?

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

5.3.4. Where Can I Learn More?


Previous Page
Next Page