Encap Package Management

Encap is a package management system developed here at UIUC. It is based around managing the contents of /usr/local, which is where most installed programs live on a Unix system. By default, these programs install themselves into `/usr/local/{bin|man|etc}'; with encap, though, the programs are installed into `/usr/local/encap/program/{bin|man|etc}', and are symbolically linked into `/usr/local/{bin|man|etc}' later. This has several advantages:

  • New versions of software can be tried out and installed without sacrificing the older versions.
  • No-longer needed packages can be easily removed for any reason.
  • This system keeps an accurate list of what files belong to what programs.
  • Anybody can tell at a glance what pacakges are installed by looking through `/usr/local/encap'.
  • You can always tell what version of a package is installed by looking in `/usr/local/encap'.

Most importantly, this system is transparent to the end user - to them, everything acts like it was just in `/usr/local', as normal. The only work necessary is during package installation.

To truly understand encap, I recommend checking out the Encap FAQ.

Software Installation

The short of it: most packages nowadays use autoconf, and this is particularly well suited for use with encap. All you have to do is set --prefix to make it go into `/usr/local/encap/[$package-$version]' instead of the default, typically `/usr/local'.

The introduction to the long version: the philosophy behind encap is that everything should go into /usr/local/encap/[$package-$version]. Of course, this isn't always possible (for instance, ssh keys still have to live in /etc most of the time, and X likes to put things in /var); still, it's a worthy goal. But to do this often involves a lot of hacking Makefiles and the like. So make sure you know what you're doing before you start.

Epkg

epkg is the standard encap package managing utility (in as much as it's the only one currently being maintained, to the best of my knowledge). It must be run as root, and symlinks all of the appropriate files from the encap directory into /usr/local.

Some other useful commands:

  • epkg [package] +1: moves the package forward one version
  • epkg [package] -1: moves the package backward one version
  • sepkg [package] : Used for upgrading packages in /Common, according to tskirvin; -kvandivo

An example: installing ssh-1.2.27

gunzip ssh-1.2.27.tar.gz tar -xvf ssh-1.2.27.tar cd ssh-1.2.27 ./configure --prefix=/usr/local/encap/ssh-1.2.27 make sudo make install sudo epkg ssh

Pre-/Post- Install Scripts

These things exist - you can tell epkg to run a script to do things before and/or after you install the package. This is useful for things like encapping ssh, and giving an easy client script to create the ssh keys in /etc. I'll write more about this later on, but for now, you should at least know that this capability is there.

encapinfo files

encapinfo files allow you to better control what is linked into place by epkg. For example, the encapinfo file from apache-1.3.12 on Sun reads:

encap 2.0 platform SunOS-5.7 date Thu Sep 14 14:28:02 CDT 2000 contact "Tim Skirvin" exclude htdocs exclude logs exclude icons exclude cgi-bin exclude conf exclude proxy

All of the files in htdocs/, logs/, etc are not linked into `/usr/local'. You can create a basic encapinfo file with 'mkencap', and more information is available in the encap home page.

Encapping Perl

Perl modules can be installed in the Encap tree with CPANencap, which documents itself pretty thoroughly. The `cpanencap' man pages should help.

Known Problems

  • We haven't gotten epkg to compile on the alphas yet. Instead I've got encapper, which is a single-source-file binary that does most of it. You have to type out the whole package name, though. For instance, the above example would have been
    sudo encapper -a ssh-1.2.27"
  • X-Windows tends to not use standard configuration scripts for just about anything. The only solution to this is to install X into /usr/local and use a judicious amount of DESTDIR and ProjectRoot variables to make things go to the right places - I've got some black magic emails that explain how to do this, but it's not pretty. But it is possible to solve this problem, which is better than some programs.
  • Some packages don't use autoconf, but can be coaxed into using encap with a little Makefile editing and file moving.
  • In general, anything reasonably large that doesn't use autoconf doesn't work with encap, unless it was designed to. This isn't going to be solved without beating all of the software writers of the world upside the head.

Contacts

References