This chapter provides an introduction to the ESP Package Manager ("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.
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.
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.
| 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 |
| dpkg | Corel 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 | OS X | Yes | No | No | Yes | No | No | No | No | No | No |
| pkgadd | Solaris | Yes | No | Yes | No | Yes | Yes | No | Yes | Yes | Yes |
| rpm | Mandrake Red Hat SuSE TurboLinux |
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 |
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.
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.
The EPM project page provides access to the current software, documentation, and mailing list for EPM:
https://www.msweet.org/projects.php/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.