You'll see on-screen output similar to this:
Preparing...
################################# [1ØØ%]
1:rcs
################################# [1ØØ%]
A major problem that package managers help solve is the dependency problem. As a Windows administrator, you deal with dependencies every day. Certain applications won't work with a given version of a DLL, or you must have one application installed before another will work. Dependency problems also occur in Linux.
RPM alone doesn't totally solve the problem; it provides the information you need to solve the problem. With RPMs, if you try to install software that has a failed dependency, (i.e., you don't have the required software installed), the rpm command will fail, and it will list which dependencies caused it to fail. You must then determine what to install to solve the dependency, which isn't necessarily a simple task. Fortunately, most package managers provide a way to discover dependencies. For example, various add-ons to RPM (e.g., Novell's ZENworks Linux Management) can address dependencies, as can the APT system (which is based on Debian). APT tells you which dependencies you need to address and automatically installs the software needed to address them. APT (http://www.debian.org/doc/manuals/apt-howto/index.en.html) offers an excellent way to learn about dependencies.
Removing packages. When you use a package manager to install software, always use the package manager to remove the software. Doing so removes the software cleanly and restores any original settings. (This practice is akin to running Uninstall for a Windows program rather than merely deleting the application directory under \Program Files.)
With RPM, you use the -e (erase) option to remove a package, as follows:
# rpm -e rcs
Dependencies might again come into play. Suppose you have tools installed that rely on the RCS package (e.g., a graphical RCS front end). If you used RPM to install the graphical front end, it will have registered RCS as a dependency. RPM will abort if you try to remove RCS while the graphical front end is installed, as the following error message shows:
# rpm -e rcs
error: Failed dependencies:
/usr/bin/ci is needed by (installed)
graphic-rcs-1.1.0
(The message wraps to several lines here because of space constraints.) When you encounter this situation, you have options. The first is to remove graphic-rcs, then remove RCS. This option ensures that you don't have orphaned applications installed that won't run correctly because they don't have required software installed. The second option is to force rpm to remove RCS despite the dependency error, as follows:
# rpm -ef rcs
Note that the use of the -f (force) option is typically not recommended. The only time this option might be desirable is when you need to remove the existing RPM installation to install an application from source.
The kinds of dependencies I've described rarely occur in Windows. Most Windows applications include all the tools they need to run, although you might experience problems with DLL versions. Linux and UNIX, however, can have a much larger set of dependencies between software packages. Keep this difference in mind when you install and remove Linux applications. Also, note that RPMs can conflict with one another (i.e., different versions of software ask for different versions of RPMs).
Binary-Only Installation
Finally, commercial software vendors often offer binary-only releases for Linux systems. That is, they offer an installation package that doesn't use a package manager but also doesn't include the source code to compile.
By using a binary-only installation method, vendors don't have to release several versions of the software to support different Linux distributions. Instead, they compile the application so that it doesn't depend heavily on the underlying system. They often use static linking of necessary libraries instead of relying on the underlying dynamic library loader (the dynamic library loader works similarly to a DLL in Windows). Still, some vendors support binary-only releases only on specific versions of Linux (e.g., Red Hat, SUSE).
Most binary-only installations are contained in tarballs, archives of files created with the UNIX tar utility. A tarball is a gzipped (compressed) tar package, with an extension of .tgz or tar.gz. Binary-only installations typically contain an install script that installs the package, as follows:
# tar xfz application.tgz
# cd application/
# ./install
where application is the name of the application file that you're installing. The actual details for an application can differ. Read the accompanying Install file or Readme file as well as any other documentation the application vendor supplies.
You'll rarely find an easy uninstall option. Some binary-only installation packages include an uninstall script, but most require that you manually delete files, as I mentioned previously.
Installation Made Easy
By using package managers to automate much of the software-installation?management task, you'll find managing software installation in Linux somewhat similar to managing that process in Windows. And with knowledge of source-installs, package manager installs, and binary-only installs, you can manage even the thorniest of software installations.
End of Article
