Running Linux, 4th Ed.Running Linux, 4th Ed.Search this book
PreviousNext

7.3. General Upgrade Procedure

Of course, you'll have to periodically upgrade other pieces of your system. As discussed in the previous section, it's usually easier and best to upgrade only those applications you need to upgrade. For example, if you never use Emacs on your system, why bother keeping up-to-date with the most recent version of Emacs? For that matter, you may not need to stay completely current with oft-used applications. If something works for you, there's little need to upgrade.

Modern Linux systems provide various ways of upgrading software, some manual (which ultimately are the most flexible, but also the most difficult), others quite automated. In this section, we'll look at three different techniques: using the RPM package system, using the Debian package system, and doing things manually.

We'd like to stress here that using packages and package systems is convenient, and even if you are a power-user, you might want to use these techniques because they save you time for other, more fun stuff. Here is a short summary of the advantages:

Of course, package systems also have a few disadvantages, some of which we discuss when we talk about RPM and the Debian package system. A generic problem is that once you start using a package system (which is almost a requirement if you use the distributions' automated installation interfaces) you ought to really install everything through packages. Otherwise, you can't keep track of the dependencies. For the same reason, mixing different package systems is a bad idea.

7.3.1. Using RPM

RPM, the Red Hat Package Manager, is a tool that automates the installation of software binaries and remembers what files are needed so that you can be assured the software will run properly. Despite the name, RPM is not Red Hat-specific, but is used in many other distributions nowadays, including SuSE and Caldera. Using RPM makes installing and uninstalling software a lot easier.

The basic idea of RPM is that you have a database of packages and the files that belong to a package. When you install a new package, the information about this package is recorded in the database. Then, when you want to uninstall the package for every file of the package, RPM checks whether other installed packages are using this file too. If this is the case, the file in question is not deleted.

In addition, RPM tracks dependencies. Each package can be dependent on one or more other packages. When you install a package, RPM checks whether the packages the new package is dependent on are already installed. If not, it informs you about the dependency and refuses to install the package.

The dependencies are also used for removing packages: when you want to uninstall a package that other packages are still dependent upon, RPM tells you about this, too, and refuses to execute the task.

The increased convenience of using RPM packages comes at a price, however: first, as a developer, it is significantly more difficult to make an RPM package than to simply pack everything in a tar archive. And second, it is not possible to retrieve just one file from an RPM package; you have to install everything or nothing.

If you already have an RPM system, installing RPM packages is very easy. Let's say that you have an RPM package called SuperFrob-4.i386.rpm (RPM packages always have the extension .rpm; the i386 indicates that this is a binary package compiled for Intel x86 machines). You could then install it with: 

tigger # rpm -i SuperFrob-4.i386.rpm

Instead of -i, you can also use the long-named version of this option; choose whatever you like better: 

tigger # rpm - -install SuperFrob-4.i386.rpm

If everything goes well, there will be no output. If you want RPM to be more verbose, you can try: 

tigger # rpm -ivh SuperFrob-4.i386.rpm

This prints the name of the package plus a number of hash marks so that you can see how the installation progresses.

If the package you want to install needs another package that is not yet installed, you will get something like the following: 

tigger # rpm -i SuperFrob-4.i386.rpm
failed dependencies:
        frobnik-2 is needed by SuperFrob-4

If you see this, you have to hunt for the package frobnik-2 and install this first. Of course, this package can itself be dependent on other packages.

If you want to update a package that is already installed, use the -U or - -update option (which is just the -i option combined with a few more implied options): 

tigger # rpm -U SuperFrob-5.i386.rpm

Uninstalling a package is done with the -e or - -erase option. In this case, you do not specify the package file (you might not have that around any longer), but rather, the package name and version number: 

tigger # rpm -e SuperFrob-5

Besides the options described so far that alter the state of your system, the -q option provides various kinds of information about everything that is recorded in the RPM database as well as package files. Here are some useful things you can do with -q:

What we've just finished showing are the basic modes of operation, which are supplemented by a large number of additional options. You can check those in the manual page for the rpm(8) command.

If you are faced with an RPM package that you want to install, but have a system like Slackware or Debian that is not based on RPM, things get a little bit more difficult.

You can either use the fairly self-explanatory command alien that can convert between various package formats and comes with most distributions, or you can build the RPM database from scratch.

The first thing you have to do in this latter case is to get the rpm program itself. You can download it from http://www.rpm.org. Follow the installation instructions to build and install it; if you have the C compiler gcc installed on your system, there should be no problems with this.

The next task is to initialize the RPM database. Distributions that come with RPM do the initialization automatically, but on other systems you will have to issue the command: 

tigger # rpm - -initdb

This command creates several files in the directory /var/lib/rpm. The directory /var/lib should already exist; if it doesn't, create it with the mkdir command first.

Now you can install RPM packages the normal way, but because you have not installed the basic parts of the system, such as the C library with RPM, you will get errors like the following: 

tigger # rpm -i SuperFrob-4.i386.rpm
failed dependencies:
        libm.so.5 is needed by SuperFrob-4
        libdl.so.1 is needed by SuperFrob-4
        libc.so.5 is needed by SuperFrob-4

because those files are not recorded in the RPM database. Of course, you really do have those files on your system; otherwise most programs wouldn't run. For RPM to work, you must tell it not to care about any dependencies. You do this by specifying the command-line option - -nodeps: 

tigger # rpm -i - -nodeps SuperFrob-4.i386.rpm

Now, RPM will install the package without complaining. Of course, it will run only if the libraries it needs are installed. The mere fact that you use - -nodeps doesn't save you when the "dependent" library or software is not installed on your system.

With this information, you should be able to administer your RPM-based system. If you want to know more, read the manual page for the rpm command, or check out http://www.rpm.org.

Some commercial companies sell automated upgrade services based on RPM. As a subscriber to these services, you can have your system upgraded automatically; the service finds out which new packages are available and installs them for you. If you use the SuSE distribution, SuSE provides such a service for free. Even the Debian distribution (whose package system is described in the next section) has an automated upgrade system (described there). However, some security experts consider these automated upgrades a security risk.

7.3.2. Using dpkg and apt

After rpm, the most popular package manager for Linux distributions is dpkg, which is used to manage .deb archives; as the name implies, the .deb format originated with the Debian distribution, but it is also used by Libranet and Xandros, among other vendors. Like the RPM format, the .deb format keeps track of dependencies and files to help ensure your system is consistent.

The technical differences between the two formats are actually fairly small; although the RPM and .deb formats are incompatible (for example, you can't install a Debian package directly on Red Hat), you can use alien to translate .deb packages for other distributions (and vice versa). The main difference between the formats is that .deb packages are built using tools that help make sure they have a consistent layout and generally conform to policies (most notably, the Debian Policy Manual, provided in the debian-policy package) that help developers create high-quality packages.

While dpkg is the low-level interface to the Debian package manager, most functions are usually handled through either the apt suite of programs or frontends like dselect, aptitude, gnome-apt, synaptic, or kpackage.

Installing .deb packages on a Debian system is quite easy. For example, if you have a package named superfrob_4-1_i386.deb, you can install it with: 

tigger # dpkg -i superfrob_4-1_i386.deb
Selecting previously deselected package superfrob.
(Reading database ... 159540 files and directories currently installed.)
Unpacking superfrob (from superfrob_4-1_i386.deb) ...
Setting up superfrob (4-1) ...

If the superfrob package is missing a dependency, dpkg will issue a warning message: 

tigger # dpkg -i superfrob_4-1_i386.deb
Selecting previously deselected package superfrob.
(Reading database ... 159540 files and directories currently installed.)
Unpacking superfrob (from superfrob_4-1_i386.deb) ...
dpkg: dependency problems prevent configuration of superfrob:
 superfrob depends on frobnik (>> 2); however:
  Package frobnik is not installed.
dpkg: error processing superfrob (- -install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 superfrob

The output indicates that you would need frobnik Version 2 or later for the package to install completely. (The files in the package are installed, but they may not work until frobnik is installed too.)

Unlike RPM, dpkg doesn't make a distinction between installing a new package and upgrading an existing one; the -i (or - -install) option is used in both cases. For example, if we want to upgrade superfrob using a newly downloaded package superfrob_5-1_i386.deb, we'd simply type: 

tigger # dpkg -i superfrob_5-1_i386.deb
(Reading database ... 159546 files and directories currently installed.)
Preparing to replace superfrob 4-1 (using superfrob_5-1_i386.deb) ...
Unpacking replacement superfrob ...
Setting up superfrob (5-1) ...

To uninstall a package, you can use either the -r (- -remove) or -P (- -purge) options. The - -remove option will remove most of the package, but will retain any configuration files, while - -purge will remove the systemwide configuration files as well. For example, to completely remove superfrob: 

tigger # dpkg -P superfrob
(Reading database ... 159547 files and directories currently installed.)
Removing superfrob ...

dpkg can also be used to find out what packages are installed on a system, using the -l (- -list) option: 

tigger $ dpkg -l
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  a2ps           4.13b-15       GNU a2ps 'Anything to PostScript' converter
ii  aalib1         1.4p5-10       ascii art library
ii  abcde          2.0.3-1        A Better CD Encoder
...
ii  zlib1g-dev     1.1.3-19       compression library - development

The first three lines of the output are designed to tell you what the first three columns before each package's name mean. Most of the time, they should read ii, which means the package is correctly installed. If they don't, you should type dpkg - -audit for an explanation of what is wrong with your system and how to fix it.

You can also use the -l option with a package name or glob-style pattern; for example, you could find out what version of superfrob is installed using: 

tigger $ dpkg -l superfrob
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  superfrob      4-1            The superfrobulator

dpkg can also be used to find out what package to which a particular file belongs: 

tigger $ dpkg - -search /bin/false
shellutils: /bin/false
tigger $ dpkg - -search /home/kalle/.xinitrc
dpkg: /home/kalle/.xinitrc not found.

You can also display information about an installed package or .deb archive: 

tigger $ dpkg - -status dpkg
Package: dpkg
Essential: yes
Status: install ok installed
Priority: required
Section: base
Installed-Size: 3156
Origin: debian
Maintainer: Dpkg Development <debian-dpkg@lists.debian.org>
Bugs: debbugs://bugs.debian.org
Version: 1.9.19
Replaces: dpkg-doc-ja
Pre-Depends: libc6 (>= 2.2.4-4), libncurses5 (>= 5.2.20020112a-1), libstdc++2.10-
glibc2.2 (>= 1:2.95.4-0.010810)
Conflicts: sysvinit (<< 2.80)
Conffiles:
 /etc/alternatives/README 69c4ba7f08363e998e0f2e244a04f881
 /etc/dpkg/dpkg.cfg 1db461ac9a1d4f4c8b47f5061078f5ee
 /etc/dpkg/dselect.cfg 190f7cf843556324495ef12759b752e3
 /etc/dpkg/origins/debian 24926c0576edec3e316fd9f6072b8118
Description: Package maintenance system for Debian
 This package contains the programs which handle the installation and
 removal of packages on your system.
 .
 The primary interface for the dpkg suite is the 'dselect' program;
 a more low-level and less user-friendly interface is available in
 the form of the 'dpkg' command.
 .
 In order to unpack and build Debian source packages you will need to
 install the developers' package 'dpkg-dev' as well as this one.
tigger $ dpkg - -info reportbug_1.43_all.deb
 new debian package, version 2.0.
 size 66008 bytes: control archive= 1893 bytes.
      40 bytes,     2 lines      conffiles
    1000 bytes,    24 lines      control
     986 bytes,    15 lines      md5sums
    1014 bytes,    41 lines   *  postinst             #!/bin/sh
     147 bytes,     5 lines   *  postrm               #!/bin/sh
     416 bytes,    19 lines   *  prerm                #!/bin/sh
 Package: reportbug
 Version: 1.43
 Section: utils
 Priority: standard
 Architecture: all
 Depends: python
 Recommends: python-newt
 Suggests: postfix | mail-transport-agent, gnupg | pgp, python-ldap (>= 1.8-1)
 Conflicts: python (>> 2.3), python-newt (= 0.50.17-7.1)
 Installed-Size: 195
 Maintainer: Chris Lawrence <lawrencc@debian.org>
 Description: Reports bugs in the Debian distribution.
  reportbug is a tool designed to make the reporting of bugs in Debian
  and derived distributions relatively painless.  Its features include:
  .
   * Integration with the mutt, af, and mh/nmh mail readers.
   * Access to outstanding bug reports to make it easier to identify
     whether problems have already been reported.
   * Support for following-up on outstanding reports.
   * Optional PGP/GnuPG integration.
  .
  reportbug is designed to be used on systems with an installed mail
  transport agent, like exim or sendmail; however, you can edit the
  configuration file and send reports using any available mail server.

dpkg can also list the files and directories included in a .deb archive: 

tigger $ dpkg - -contents superfrob_4-1_i386.deb
-rwxr-xr-x root/root     44951 2002-02-10 12:16:48 ./usr/bin/dothefrob
-rwxr-xr-x root/root     10262 2002-02-10 12:16:48 ./usr/bin/frobhelper
...

dpkg, like rpm, has numerous other options; for more details, refer to the manual pages for dpkg and dpkg-deb.

In addition to dpkg, Debian and other Debian-based distributions provide the apt suite of programs.[24] APT is the "Advanced Package Tool," and is designed as an archive-independent system that can handle multiple package formats. Perhaps the most important feature of APT is its ability to resolve dependencies automatically; if, for example, superfrob requires Version 2 or later of frobnik, APT will try to find frobnik from the sources that are available to it (including CD-ROMs, local mirrors, and the Internet).

[24]Some RPM-based distributions now include APT as well because APT was designed to work with any packaging format.

The most useful interface to APT is the apt-get command. apt-get manages the list of available packages (the "package cache") and can be used to resolve dependencies and install packages. A typical session would start with an update of the APT cache: 

tigger # apt-get update
Get:1 http://http.us.debian.org stable/main Packages [808kB]
Get:2 http://http.us.debian.org stable/main Release [88B]
Hit http://non-us.debian.org stable/non-US/main Packages
Hit http://non-us.debian.org stable/non-US/main Release
Get:3 http://security.debian.org stable/updates/main Packages [62.1kB]
Get:4 http://security.debian.org stable/updates/main Release [93B]
Fetched 870kB in 23s (37kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done

The output indicates that there have been updates to the stable distribution, so we may want to upgrade the packages already installed on the system. To do this automatically, we can use apt-get's upgrade option: 

tigger # apt-get upgrade
The following packages have been kept back:
  gnumeric
17 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 16.3MB of archives.  After unpacking 5kB will be freed.
Do you want to continue? [Y/n] y
Get:1 http://http.us.debian.org stable/main base-passwd 3.4.6 [17.2kB]
Get:2 http://security.debian.org stable/updates/main ssh 1:3.1.6p4-1 [600kB]
...
(Reading database ... 159546 files and directories currently installed.)
Preparing to replace ssh 1:3.0.3p2-6 (using .../ssh_1%3a3.1.6p4-1_i386.deb) ...
Unpacking replacement ssh ...
...

One thing you will notice is that unlike most Linux commands, the actions taken by APT commands are specified without dashes. apt-get does allow some options, but they are used only to change the behavior of the main action specified.[25]

[25]Some other Linux commands, like cvs, also act this way.

Note that gnumeric was not automatically upgraded, probably because it would have required additional packages to be installed. To upgrade it and resolve dependencies, we can use apt-get's install option, with the names of one or more packages: [26]

[26]Note that apt-get does not install packages directly from .deb archives; dpkg's - -install option should be used instead for an archive that you have in a .deb archive on disk or have downloaded directly from the Internet. When using dpkg, you will need to resolve the dependencies yourself.

tigger # apt-get install gnumeric
The following extra packages will be installed:
  libgal36 libglade3
The following NEW packages will be installed:
  libgal36
2 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 8.3MB of archives.  After unpacking 503kB will be used.
Do you want to continue? [Y/n] y
...

Another useful feature of APT is its ability to find information about packages in the repository. The apt-cache command is used to look up information about packages that are available for installation. One common use of apt-cache is to find packages based on keywords in the package's description, by using words, complete phrases (in quotes), or regular expressions. For example, if you want to find a package that allows you to play Ogg Vorbis-encoded music files, you can use the search option to find appropriate packages: 

tigger $ apt-cache search "ogg vorbis"
audacity - A fast, cross-platform audio editor
bitcollider-plugins - bitcollider plugins
cplay - A front-end for various audio players
gqmpeg - a GTK+ front end to mpg321/mpg123 and ogg123
libapache-mod-mp3 - turns Apache into a streaming audio server
libvorbis0 - The Vorbis General Audio Compression Codec
mp3blaster - Full-screen console mp3 and ogg vorbis player
mp3burn - burn audio CDs directly from MP3s or Ogg Vorbis files
oggtst - Read comments in ogg vorbis files
python-pyvorbis - A Python interface to the Ogg Vorbis library
vorbis-tools - Several Ogg Vorbis Tools
xmms - Versatile X audio player that looks like Winamp
xmms-dev - XMMS development static library and header files
mq3 - a mp3/ogg audio player written in Qt.

Now, if we are interested in one of these packages, we can find out more about it using the show option of apt-cache: 

tigger $ apt-cache show xmms
Package: xmms
Priority: optional
Section: sound
Installed-Size: 4035
Maintainer: Josip Rodin <jrodin@jagor.srce.hr>
...
Description: Versatile X audio player that looks like Winamp
 XMMS (formerly known as X11Amp) is an X/GTK+ based audio player
 for various audio formats.
 .
 It's able to read and play:
  * Audio MPEG layer 1, 2, and 3 (with mpg123 plug-in),
  * WAV, RAW, AU (with internal wav plug-in and MikMod plug-in),
  * MOD, XM, S3M, and other module formats (with MikMod plug-in),
  * CD Audio (with CDAudio plug-in), with CDDB support,
  * .cin files, id Software,
  * Ogg Vorbis files.
 It has eSound, OSS, and disk writer support for outputting sound.
 .
 It looks almost the same as famous Winamp, and includes those neat
 features like general purpose, visualization and effect plug-ins,
 several of which come bundled, then spectrum analyzer, oscilloscope,
 skins support, and of course, a playlist window.

While a full exploration of APT's features was beyond the scope of this chapter, the apt manual page (and the manual pages it references) along with the APT HOWTO (available in the apt-howto-en package) should answer any questions you may have.

In addition to the command-line tools, a number of easy-to-use text-based and graphical frontends have been developed. One of the most mature frontends is kpackage, which is part of the KDE Desktop Environment, but can be used with other desktops such as GNOME. kpackage can be run from the command line or found in the System menu of KDE. Figure 7-1 shows a sample screen from kpackage.

Figure 7-1

Figure 7-1. kpackage package manager

The main window of kpackage displays a list of all the packages available for your system on the left, with a box to the right; when you choose a package in the list, the box to the right includes information about the package you selected. You can install or uninstall packages by selecting them and choosing Install or Uninstall from the Packages menu, or by clicking the column labeled Mark to place a checkmark next to them, and then clicking the Install marked or Uninstall marked buttons. You can also install .deb packages directly by clicking the Open button on the toolbar to the left of the screen and selecting the file, or dragging .deb icons from KDE file manager windows into kpackage's window. kpackage also has tools for finding packages with particular names. Like all KDE applications, kpackage has help available by pressing F1 or using the Help menu.

7.3.3. Upgrading Other Software

In order to upgrade other applications, you'll have to obtain the newest release of the software. This is usually available as a gzipped or compressed tar file. Such a package could come in several forms. The most common are binary distributions, in which the binaries and related files are archived and ready to unpack on your system, and source distributions, in which the source code (or portions of the source code) for the software is provided, and you have to issue commands to compile and install it on your system.

Shared libraries make distributing software in binary form easy; as long as you have a version of the libraries installed that is compatible with the library stubs used to build the program, you're set. However, in many cases, it is easier (and a good idea) to release a program as source. Not only does this make the source code available to you for inspection and further development, but it also allows you to build the application specifically for your system, with your own libraries. Many programs allow you to specify certain options at compile time, such as selectively including various features in the program when built. This kind of customization isn't possible if you get prebuilt binaries.

There's also a security issue at play when installing binaries without source code. Although on Unix systems viruses are nearly unheard of,[27] it's not difficult to write a "Trojan Horse," a program that appears to do something useful but, in actuality, causes damage to the system. For example, someone could write an application that includes the "feature" of deleting all files in the home directory of the user executing the program. Because the program would be running with the permissions of the user executing it, the program itself has the ability to do this kind of damage. (Of course, the Unix security mechanism prevents damage being done to other users' files or to any important system files owned by root.)

[27]A "virus" in the classic sense is a program that attaches to a "host," which runs when the host is executed. On Unix systems, this usually requires root privileges to do any harm, and if programmers could obtain such privileges, they probably wouldn't bother with a virus.

While having source won't necessarily prevent this from happening (do you read the source code for every program you compile on your system?), at least it gives you a way to verify what the program is really doing. Also, if source code is available, it is likely that some people will peruse it so that using source is a bit safer; but you can't count on that.

At any rate, dealing with source and binary distributions of software is quite simple. If the package is released as a tar file, first use the tar t option to determine how the files have been archived. In the case of binary distributions, you may be able to unpack the tar file directly on your system — say, from / or /usr. When doing this, be sure to delete any old versions of the program and its support files (those that aren't overwritten by the new tar file). If the old executable comes before the new one on your path, you'll continue to run the old version unless you remove it.

Source distributions are a bit trickier. First, you must unpack the sources into a directory of their own. Most systems use /usr/src for just this. Because you usually don't have to be root to build a software package (although you will usually require root permissions to install the program once compiled!), it might be a good idea to make /usr/src writable by all users, with the command: 

chmod 1777 /usr/src

This allows any user to create subdirectories in /usr/src and place files there. The first 1 in the mode is the "sticky" bit, which prevents users from deleting each other's subdirectories.

You can now create a subdirectory under /usr/src and unpack the tar file there, or you can unpack the tar file directly from /usr/src if the archive contains a subdirectory of its own.

Once the sources are available, the next step is to read any README and INSTALL files or installation notes included with the sources. Nearly all packages include such documentation. The basic method used to build most programs is:

  1. Check the Makefile. This file contains instructions for make, which controls the compiler to build programs. Many applications require you to edit minor aspects of the Makefile for your own system; this should be self-explanatory. The installation notes will tell you if you have to do this. If there is no Makefile in the package, you might have to generate it first. See item 3 for how to do this.

  2. Possibly edit other files associated with the program. Some applications require you to edit a file named config.h; again, this will be explained in the installation instructions.

  3. Possibly run a configuration script. Such a script is used to determine what facilities are available on your system, which is necessary to build more complex applications.

    Specifically, when the sources do not contain a Makefile in the top-level directory, but instead a file called Makefile.in and a file called configure, the package has been built with the Autoconf system. In this (more and more common) case, you run the configuration script like this: 

    ./configure

    The ./ should be used so that the local configure is run, and not another configure program that might accidentally be in your path. Some packages let you pass options to configure that often enable or disable specific features of the package. (You can find out what these options are with configure - -help.) Once the configure script has run, you can proceed with the next step.

  4. Run make. Generally, this executes the appropriate compilation commands as given in the Makefile. In many cases you'll have to give a "target" to make, as in make all or make install. These are two common targets; the former is usually not necessary but can be used to build all targets listed in a Makefile (e.g., if the package includes several programs, but only one is compiled by default); the latter is often used to install the executables and support files on the system after compilation. For this reason, make install is usually run as root.

    Even after the installation, there is often one major difference between programs installed from source or from a binary package. Programs installed from source are often installed below /usr/local by default, which is rarely the case with binary packages.

You might have problems compiling or installing new software on your system, especially if the program in question hasn't been tested under Linux, or depends on other software you don't have installed. In Chapter 13, we talk about the compiler, make, and related tools in detail.

Most software packages include manual pages and other files, in addition to the source and executables. The installation script (if there is one) will place these files in the appropriate location. In the case of manual pages, you'll find files with names such as foobar.1 or foobar.man. These files are usually nroff source files, which are formatted to produce the human-readable pages displayed by the man command. If the manual page source has a numeric extension, such as .1, copy it to the directory /usr/man/man1, where 1 is the number used in the filename extension. (This corresponds to the manual "section" number; for most user programs, it is 1.) If the file has an extension such as .man, it usually suffices to copy the file to /usr/man/man1, renaming the .man extension to .1.

PreviousHomeNext
7.2. Upgrading SoftwareBook Index7.4. Building a New Kernel
Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.