Chapter 27. Package Management Systems

Objectives

• Explain why software package management systems should be used
• Understand the role of both binary and source packages
• List the main available package management systems
• Understand why two levels of utilities are needed
  • One that deals with just bare packages
  • One that deals with dependencies among packages
• Explain how creating your own package enhances the control you have over exactly what goes in software and how it is installed
• Understand the role of source control systems and git in particular

Software Packaging Concepts

This allows the system administrators to Automate

• Installation process
• Software upgrading
• Configuration
• Software removal

These are some of the features of these system

• Package software and its dependencies
• Allow easy software installation and removal
• Certify integrity of the software with an internal Data Base
• Can authenticate the origin of the packages
• Facilitates upgrades
• Group packages by logical features
• Manage dependencies between packages

These packages can contain several different sort of files, including scripts, dependencies, and metadata like checksums, description files and so on. Once the software is installed data about it will be store in a database that can be queried later for information purposes.

Why use packages

Because it allows

• Automation
• Scalability
• Repeatability and predictability
• Security and Auditing

Packages Types

They come in several different types

• Binary
  • Architecture dependent packages, need to be compiled for each type of machine
• Source
  • Packages used to generate binary packages. These can be used for several architectures
• Architecture-independent
  • Contain files that can be run under script interpreters
• Meta-packages
  • Groups of associated packages needed to install a large system, such as a desktop environment

Available Package Management Systems

There are two very common package management systems

• RPM
  • Red hat Package Management system
    • Used by
      • Red Hat Enterprise Linux
      • CentOS
      • Scientific Linux
      • SUSE
      • openSUSE
• DPGK
  • Debian Package
    • Used by
      • Debian
      • Ubuntu
      • Linux Mint

There are other like

• Gentoo
• Pacman
• Arch
• Other used for Embedded Linux and Android

Packaging Tool levels and Varieties

Two levels to packaging systems

• Low Level Utility
  • Simply install or removes a single package. It will not handle dependencies
• High Level Utility
  • This handles dependencies
    • yum and zypper handle this for RPM
    • apt-get and apt-cache handle this for DPKG

Package Sources

Every distribution has one or more package repositories where sustem utilities go to obtain software and to update with new versions. It is the job of the distrubution to make sure all packages in the repositories play well with each other.

There are always other external repositories, which can be added to the standard distribution-supported list. Sometimes these are closely associated with the distribution and only rarely produce significant problems. 

An example will be the EPEL repository (Extra Packages for Enterprise Linux) set of version-dependent repositories, which fit well with RHEL since their source is Fedora and the maintainers are close to Red Hat.

However some external repositories are not well maintained. For example when a package is updated in the main repository, dependent packages may not be updated in the external one, which can lead to one form of dependency hell.

Creating Software Packages

Building your own custom software packages makes it easy to distribute and install your own software. Almost all linux distributions has some mechanism to make this.

Building your own custom package will allow us to run the scripts that will do exactly what we want it to run or execute such as

• Creating needed symbolic links
• Creating directories as needed
• Setting permissions
• Anything that can be scripted

Revision Control Systems

In order to maintain a sort of log and history of the changes in a given software a tool is required to accomplish such task. Today we have GIT as a child from Linux. 

Available Source Control Systems

• RCS
• CVS
• Subversion
• GIT
• GNU Arch
• Monotone
• Mercurial
• PRCS

How GIT works

It has 

• Object database
• Directory cache

The object database contains

• Blobs
  • Chunks of binary data containing file contents
• Trees
  • Sets of blobs including file names and attributes, giving the directory structure
• Commits
  • Changesets describing tree snapshots

The Directory cache captures the state of the directory tree