Partial preview of the text
Download UNIX and Linux System Administration and more Schemes and Mind Maps Linux skills in PDF only on Docsity!
6.2 MANAGING PACKAGES UNIX and Linux software assets (source code, build files, documentation, and configuration templates) were traditionally distributed as compressed archives, usually gzipped tarballs (.tar.gz or .tgz files). This was OK for developers but inconvenient for end users and administrators. These source archives had to be manually compiled and built for each system on each release of the software, a tedious and error prone process. Packaging systems emerged to simplify and facilitate the job of software management. Packages include all the files needed to run a piece of software, including precompiled binaries, dependency information, and configuration file templates that can be customized by administrators. Perhaps most importantly, packaging systems try to make the installation process as atomic as possible. If an error occurs during installation, a package can be backed out or reapplied. New versions of software can be installed with a simple package update. Package installers are typically aware of configuration files and will not normally overwrite local customizations made by a system administrator. They either back up existing config files that they change or supply example config files under a different name. If you find that a newly installed package breaks something on your system, you can, theoretically, back it out to restore your system to its original state. Of course, theory != practice, so don’t try this on a production system without testing it first. Packaging systems define a dependency model that allows package maintainers to ensure that the libraries and support infrastructure on which their applications depend are properly installed. Unfortunately, the dependency graphs are sometimes imperfect. Unlucky administrators can find themselves in package dependency hell, a state where it’s impossible to update a package because of version incompatibilities among its dependencies. Fortunately, recent versions of packaging software seem to be less susceptible to this effect. Packages can run scripts at various points during the installation, so they can do much more than just disgorge new files. Packages frequently add new users and groups, run sanity checks, and customize settings according to the environment. Confusingly, package versions do not always correspond directly to the versions of the software that they install. For example, consider the following RPM package for docker-engine: $ rpm -ga | grep -i docker docker-engine-1.13.0-1.e17.centos.x86_64 $ docker version | grep Version Version: 1.13.4 The package itself claims version 1.13.0, but the docker binary reports version 1.13.1. In this case, the distribution maintainers backported changes and incremented the minor package 
