Controlling the package build process

This page contains a brief overview of how to build Debian packages from the source for the iHRIS Suite. The package building scripts are bootstrapped when the I2CE package is built. The packaging scripts reside in modules/PackageUtils/.

Goals of PackageUtils

The PackageUtils module was designed with a few goals in mind. These are

• One module, one package
• Minimize configuration information
• Ease of invocation
• Compatibility with Launchpad's PPA service

One Module, One Package

There is a one-to-one correspondence between modules and debian packages. The package name corresponds to the name attribute of the I2CEConfiguration element in the XML file. An “i2ce-” prefix is given to each generated package to reduce the changes of naming conflicts. (The only exception to this is the I2CE package itself which is named simply “i2ce”.) In this way, dependencies between packages mirror the dependencies between modules.

Minimize configuration information

Another goal of the current design was to eliminate the need to maintain dozens of different configuration files for each module. The information needed was (mostly) already found in the configuration file.

For this reason, PackageUtils relies on a module's configuration for all of its information. This information is put into some templates (which are found in the templates/ subdirectory of the PackageUtils module) to produce a debian/ directory that is used to build the entire package. Source packages are also produced during the build process. The source packages are needed so that Launchpad can build the packages using standard Debian tools.

Ease of invocation

The PackageUtils module (i2ce-package-utils) is set up so that it could be run from the root of a checkout of I2CE code (e.g. the results of bzr co lp:i2ce or bzr co lp:ihris-manage) and, from a single command, create packages for all modules in that source tree.

Compatibility with Launchpad's PPA service

During the build process, the modules are put into a conventional layout so that conventional tools (such as dpkg-source and debuild) can be used to manipulate the packages.

Part of the build process is to run debuild -S to produce a _source.changes file that can be used with dput to upload to Launchpad's build service.

Running the package builder

After installing PackageUtils (sudo apt-get install i2ce-package-utils), from the top level of an I2CE source tree you can run build-i2ce.

The site modules are handled seperately and must be built by hand. So, if you want to build the Demo site module, use the following steps:

   $ bzr co lp:ihris-manage
   $ cd ihris-manage/sites/Demo
   $ build-i2ce

The resulting debian package (in pkgs/DEB/) must be manually uploaded to the repository.

Note: there is a bug in the build process. I designed it to follow all the paths for MODULES so it could be run in a top-level tree. However, since the Demo site module includes a ../../.. path (which you should change to /usr/share/i2ce at the time of build), it will try to traverse those directories as well. This behavior will be fixed, but, for now, you can safely break out of the build after it has built the demo package.

Note: At this point, build-i2ce will build all modules and there is no way to specify a single module to build. Since I initially intended build-i2ce to be run automatically by Continuum, this wasn't a concern.

Special Paths

The prepInstallPaths method specifies two special path names from the paths listed in the configuration file. Files from any other specified path are installed under /usr/share/i2ce/.

The two specified paths are BIN and CONF. Files in the path specified by BIN are installed to /usr/bin/ while files under the path specified by CONF are installed under /etc/i2ce. (As of this writing this is used only by PackageUtils itself to install build-i2ce and deploy-i2ce and their configuration file.)

Additional modifications can be made here so that files under, say, PAGES are installed under /var/www/i2ce.

FIXME: The path-mapping information in prepInstallPaths should probably be moved to a configuration file.