|
RPM is short for Red Hat Package Manager. First used
by the Red Hat Linux distribution (obviously ;)), it is now the package format
of choice for most major distributors: SuSE, Caldera, Conectiva and - of
course - Mandrakesoft, to name a few.
What is a 'package', then? A package is an archive:
it contains all the files which belong to a certain application, program
library or whatever the package name indicates. Think of an ZIP or an TAR
archive. But apart from this (compressed) archive, the package also contains
control scripts. These control scripts are read, executed and stored by the
local RPM installation and handle things like installation, deinstallation,
status checking, dependencies etc.
Packages are built by package maintainers using a so-called 'specfile' (specification
file) which determines where the files of a package are going to be installed
to, which other packages are needed by the package in order to work correctly,
what programs to execute before or after installing or uninstalling a package,
but also information on who built the package and when, a description of
the purpose of the content of the package and much more.
In order to work efficiently, RPM needs to keep track
of which packages are installed on a system. This database is located in
'/var/lib/rpm'. As you will see, this database also allows you to extract
lots of useful information about installed programs.
 section index  top
Among the things RPM and the package maintainer do for
you are:
-
Compiling and patching the program's source code.
This is convenient especially for new users. Compiling source code and applying patches requires
some advanced knowledge, although it's by no means black magic. But even
if you know enough to compile sources on your own, RPM comes in handy when
you just can't be bothered with compiling or the sources are large or known
to be tricky to handle.
-
Handling dependencies. In contrast to monolithic
operating systems like Windows, Linux systems can differ from each other
pretty much depending on installation size, intended use of system, personal
preferences of the user etc.
Now instead of equipping all Linux systems with all the necessary files,
you select the files, programs, program libraries you want. When you are
about to install a new program, RPM will check if you've got everything installed
needed to run the program successfully. And what's even more important, it
will prevent you from accidentally removing packages which are essential
for other packages or even your system as a whole.
-
Providing information on file status. RPM provides
you with many possibilities to inquire the status of packages, be they installed
or not. You can check new packages for integrity before you install them
and check afterward if they have been installed correctly. You can find out
which package has been installed when, how much space it takes up, which documentation
or configuration files are included, recent changes applied to the package
by the package maintainer and more.
-
Security checks. RPM provides a mechanism to sign
packages with a PGP or GPG
signature. This way you can make sure that the package has not been tampered
with.
-
Automation. RPM can and is used in many scripts
to automate maintenance tasks. It also provides the sound foundation for
graphical RPM tools and extensions like 'rpmfind' or Mandrake Linux' own
'urpmi' system.
-
Clean removal. It just takes one command to remove
an RPM from your system. This command will remove everything except for files
changed during the installation time of the package (usually configuration
or spool files).
-
Preserve configuration files. The package maintainer
can decide how to handle configuration files of older package versions. He
can either leave them in place and create the new versions as 'rpmnew' files,
or he tells RPM to rename the old configuration files to 'rpmsave' files
and put the new versions in their place.
-
Discrimination between runtime and compile time
files. Packages containing program libraries are split in runtime and compile
time ('devel') packages. If you don't compile source yourself, you don't
need to install the 'devel' packages. Or you can install them when you want
to compile some software and remove them again afterward.
-
Network capability. It doesn't matter to RPM if
the packages it is told to operate on are on a local file system, an NFS
mount or an FTP server, as long as you provide the full path to the file(s).
-
Easy rebuilding. Every RPM containing Free or Open
Source software stems from a 'Source RPM' (aka SRPM or 'src.rpm'). This SRPM
contains everything which is needed to build the related RPM(s).
This can be useful if you want to use different compile time options or simply
adept the package to your specific system environment (release, kernel version,
library versions etc), without getting the source yourself, applying all
the needed patches and so forth.
section index top
Like every tool, RPM has its limitations:
-
No automatic resolution of dependencies. RPM will
tell you what's missing, but it won't fetch and install it for you. This
major limitation can be - at least partly - overcome by using extension tools
like Mandrake Linux' 'urpmi' or the generic 'rpmfind' script.
-
No interactive configuration. Vendor supplied packages
usually contain adapted configuration files and post-installation scripts.
Interactive configuration steps however must be taken separately from installation
(if needed).
-
No protection from packaging errors. We all make
mistakes, and package maintainers are no exception. Incorrect specfiles can
prevent a packaged program from running properly after installation. In theory
it is even possible to use RPM to intentionally damage a system (since installation
has to be done as 'root'). Therefore you should only use packages from trusted
parties.
-
No compatibility guarantee. RPM is used by many
Linux distributors and independent persons. Different packaging policies
might prevent a package either from installing or the included program from
running after installation (e.g. by putting the executable in a different
directory than your distribution). Prefer packages from your distributor
to those of others.
-
Optimizations. It is possible to optimize RPMs for
a certain type of processor by compiling the program sources with the appropriate
options. Mandrake Linux does that for the Pentium-class (i586) of processors.
But these compiler options are just one part on a vast array of available
compiling settings.
Usually the packager will try to enable as much options as possible, which
results in bigger - and sometimes slower - executables and big packages with
lots of files. Bottom line: if you want fine tuning, you have to compile the sources yourself.
Although RPM is by no means perfect, it is a very versatile
tool, all the more when used in conjunction with extensions like 'urpmi'.
section index top
 Basic RPM Handling
|
