# 1 - Introduction to EPM

This chapter provides an introduction to the ESP Package Manager ("EPM").

## What is EPM?

Software distribution under UNIX/Linux can be a challenge, especially if you ship software for more than one operating system. Every operating system provides its own software packaging tools and each has unique requirements or implications for the software development environment.

The ESP Package Manager ("EPM") is one solution to this problem. Besides its own "portable" distribution format, EPM also supports the generation of several vendor-specific formats. This allows you to build software distribution files for almost any operating system from the same sources.

## History and Evolution

When Easy Software Products was founded by me in 1993, the company originally shipped software only for the SGI IRIX operating system. Support was added for Solaris in 1997, followed quickly by HP-UX in 1998.

Each new operating system and supported processor required a new set of packaging files. While this worked, it also meant keeping all of the packaging files synchronized manually. Needless to say, this process was far from perfect and there was more than one distribution that was not identical on all operating systems.

As I began developing CUPS (https://www.cups.org/) in 1997, the initial goal was to add support for two additional operating systems: Linux and Compaq Tru64 UNIX. If I was to avoid the mistakes of the past, I clearly had to change how software distributions were produced.

The first version of EPM was released in 1999 and supported so-called "portable" software distributions that were not tied to any particular operating system or packaging software. Due to popular demand, we added support for vendor-specific packaging formats in the second major release of EPM, allowing the generation of portable or "native" distributions from one program and one set of software distribution files.

## Existing Software Packaging Systems

As I looked for a solution to our problem, we naturally investigated the existing open-source packaging systems. Under Linux, I looked at the Red Hat Package Manager ("RPM") and Debian packaging software ("dpkg" and "dselect"). For the commercial UNIX's I looked at the vendor-supplied packaging systems. Table 1.1 shows the results of my investigation.

Table 1.1: Software Packaging Formats
Format | Operating Systems1 | Binaries | Cross- Platform | Patches | Up- grades | Con- flicts | Re- quires | Re- places | Config Files | Map Files | Un- install
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
installp | AIX | Yes | No | No | No | Yes | Yes | No | No | No | Yes
pkg_add | FreeBSD | Yes | Yes2 | No | No | No | No | No | No | No | Yes
pkg_add | NetBSD OpenBSD | Yes | Yes2 | No | No | Yes | Yes | No | No | No | Yes
deb | Ubuntu Linux Debian GNU/Linux | Yes | Yes2 | No | Yes | Yes | Yes | Yes | Yes | No | Yes
depot | HP-UX | Yes | No | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes
inst | IRIX | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes
Install.app | macOS | Yes | No | No | Yes | No | No | No | No | No | No
pkgadd | Solaris | Yes | No | Yes | No | Yes | Yes | No | Yes | Yes | Yes
rpm | CentOS Red Hat SuSE | Yes | Yes2 | No | Yes | Yes | Yes | No | Yes | No | Yes
setld | Tru64 UNIX | Yes | No | No | No | Yes | Yes | No | No | No | Yes
slackware | Slackware Linux | Yes | No | No | No | Yes | Yes | No | No | No | Yes

1. Standard packaging system for named operating systems.
2. These packaging systems are cross-platform but require the package management utilities to be installed on the platform before installing the package.

As you can see, none of the formats supported every feature we were looking for. One common fault of all these formats is that they do not support a common software specification file format. That is, making a Debian software distribution requires significantly different support files than required for a Solaris pkg distribution. This makes it extremely difficult to manage distributions for multiple operating systems.

All of the package formats support binary distributions. The RPM and Debian formats also support source distributions that specifically allow for recompilation and installation. Only the commercial UNIX formats support patch distributions - you have to completely upgrade a software package with RPM and Debian. All but the Solaris `pkg` format allow you to upgrade a package without removing the old version first.

When building the software packages, RPM and Debian force you to create the actual directories, copy the files to those directories, and set the ownerships and permissions. You essentially are creating a directory for your software that can be archived in the corresponding package format. To ensure that all file permissions and ownerships are correct, you must build the distribution as the root user or use the `fakeroot` software, introducing potential security risks and violating many corporate security policies. It can also make building distributions difficult when dynamic data such as changing data files or databases is involved.

The commercial UNIX formats use software list files that map source files to the correct directories and permissions. This allows for easier delivery of dynamic data, configuration management of what each distribution actually contains, and eliminates security issues with special permissions and building distributions as the root user. Using the proprietary format also has the added benefit of allowing for software patches and using the familiar software installation tools for that operating system. The primary disadvantage is that the same distributions and packaging software cannot be used on other operating systems.

## Design Goals of EPM

EPM was designed from the beginning to build binary software distributions using a common software specification format. The same distribution files work for all operating systems and all distribution formats. Supporting source code distributions was not a goal since most RPM and Debian source distributions are little more than wrapping around a compressed tar file containing the source files and a configure script.

Over the years, additional features have made their way into EPM to support more advanced software packages. Whenever possible, EPM emulates a feature if the vendor package format does not support it natively.

## Resources

The EPM project page provides access to the current software, documentation, and issue tracker for EPM:

    https://jimjag.github.io/epm/

The EPM source code can be downloaded in compressed tar files or via the popular Subversion software. Please see the EPM project page for complete instructions.