Creating Debian Packages: Difference between revisions

From IHRIS Wiki
No edit summary
Line 196: Line 196:


This contains any notes the packager may wish to include.  Don't just copy a <tt>README</tt> file as the packaging usually includes this.
This contains any notes the packager may wish to include.  Don't just copy a <tt>README</tt> file as the packaging usually includes this.
[[Category:HowTo]]

Revision as of 18:57, 3 August 2009

This document describes the decisions made in packaging and descrbes the steps taken.

For the purpose of this discussion, we'll consider the build directory to be at ~/build.

Bazaar

$ sudo aptitude install bzr

If you are creating a new project, then make a directory for the project and put it under version control. For example:

$ bzr init ihris-qualify-debian

Since you are probably dealing with code already under version control, you can just check it out. For example, to check out the my build scripts for the i2ce project from Launchpad:

$ bzr co lp:~hexmode/i2ce/debian-dev i2ce-debian
$ ls
i2ce-debian

bzr-builddeb

$ sudo aptitude install bzr-builddeb

The build scripts are kept separate repository and kept under version control. To enable this (and keep the number of revision control systems in use to a minimum), I use bzr-builddeb to build packages directly from the bzr repository.

This package generation tool can keep the debian directory under revision control. If you look at my debian repositories, you'll see that the repositories are the contents of the debian directory. During the build process, bzr-builddeb merges the directory with the pristine source tree and performs all build operations there.

bzr-builddeb uses several configuration files to control its operation. The only one we're concerned with here is the default.conf file under the .bzr-builddeb directory. This stores the defaults for this package. The contents of ~/build/i2ce-debian/.bzr-debbuild/default.conf:

[BUILDDEB]
merge = True
export-upstream = http://bazaar.launchpad.net/%7Eintrahealth%2Binformatics/i2ce/main/

The first line just confirms that this is a bzr-builddeb configuration package.

The second line (merge = True) tells bzr-builddeb to merge this directory (in this case, ~/build/i2ce-debian with the the upstream source.

The third line (export-upstream = …) gives the location of the original source in Bazaar to check out.

Running bzr builddeb from within the i2ce-debian directory will create a ~/build/build-area/i2ce-2.0 directory, check out the code from Launchpad, put the contents of the current directory in the debian subdirectory, and build the package. After the package is built, the ~/build/build-area/i2ce-2.0 directory will be removed.

dpatch

dpatch is a patch management system that I used to alter the pristine configuration files so that they would work in the Debian packages.

Patches are stored in the patches sub-directory and are applied in the order listed in the 00list file in that directory.

To apply all the patches, the command dpatch apply-all is executed. To remove all patches (i.e. in a “clean” operation), use the command dpatch deapply-all. To create a new patch, see “Creating dpatch scriptlets” in the dpatch man page.

dbconfig-common

dbconfig-common is used to set up the database structure for the i2ce. If there is any need to provide initial database data for other packages, this package should be used to handle the installation.

To setup a database, two things must be done. First, the database data must be provided. Second, the dbconfig-common post-installation hooks must be called.

The SQL data is provided during the package building process by putting an SQL file at /usr/share/dbconfig-common/data/package/install/mysql. PostgreSQL setup can be done in a similar way.

Important: Since dbconfig-common creates a database as well as a user for the application, do not perform these steps in your database setup.

In the post-installation script, a few environment variables are set to tell dbconfig-common where to place the templates it produces and then the dbconfig-common hooks are called. These hooks take care of collecting and assigning passords; creating the user and database for the application; and loading the data into the database.

ucf

Configuration files are managed with ucf (Update Configuration File).

This tool provides a way to udate configuration files so that user's changes are preserved. ucf is called from the post-installation scripts to copy over a new configuration file. If changes are detected that cannot easily be merged, the administrator performing the installtion will be prompted to confirm the update.

In the iHRIS packages, files managed with ucf are /etc/i2ce/I2CE_config.inc.php, /etc/i2ce/ihris_config.inc.php, /etc/apache2/conf.d/ihris-manage.conf, and the like.

Files and Directories in the Debian directory

The debian directories under Bazaar contain several identically named files. Here I describe the purpose of each file. To learn more about the process of creating a Debian package, see the Debian New Maintainers' Guide

.bzr

Bazaar stores all information about files under version control in this directory. I won't bother talking about the specifics of what is in here since it isn't related to the build process. Just don't delete it if you plan to use bzr-builddeb

.bzr-builddeb/default.conf

The contents of this file were explained in the [#bzr-builddeb bzr-builddeb] section.

rules

This is a makefile that controls the creating of a package. It has five mandatory targets (clean, binary, binary-arch, binary-indep, and build).

Since we're using dpatch, I've added patch and unpatch targets that build and clean depend on.

patch: patch-stamp
patch-stamp:
	dpatch apply-all -v
	dpatch cat-all > patch-stamp

unpatch:
	dpatch deapply-all
	rm -rf patch-stamp debian/patched

PHP-based packages don't really need that much “build” effort, so most of the action happens in the install target (used by the mandatory binary target) where files are re-arranged into something resembling the Filesystem Hierarchy Standard (fhs). As of this writing, for example, the i2ce package contains the following instructions:

install -d -m 755 -o root -g admin $(DESTDIR)/usr/share/ihris
install -d -m 755 -o root -g admin $(DESTDIR)/usr/share/ihris/lib
install -d -m 755 -o root -g admin $(DESTDIR)/etc/$(PACKAGE)
install -d -m 755 -o root -g admin $(SQL_DIR)

install -m 444 -o root -g admin \
	lib/*.php $(DESTDIR)/usr/share/ihris/lib

install -m 444 -o root -g admin I2CE_config.inc.php \
	$(DESTDIR)/usr/share/ihris/
install -m 444 -o root -g admin I2CE_structure.sql $(SQL_DIR)/mysql;

changelog

This is just a description of the changes to the package itself. Since it has a very specific format, use dch or Emacs' debian-changelog-mode to create new entries.

compat

(I'm not sure what this is. I believe it contains the version number the build scripts look at to make sure they build the package properly.)

control

The packages that can be produces from this debian directory as well as the description, architecture, build-dependencies and install-dependencies are listed in the file.

For example, the control file for i2ce looks like this:

Source: i2ce
Section: web
Priority: extra
Maintainer: Mark A. Hershberger <mhershberger@intrahealth.org>
Build-Depends: debhelper (>= 5), dpatch
Standards-Version: 3.7.2

Package: i2ce
Architecture: all
Pre-Depends: ucf
Depends: ${shlibs:Depends}, ${misc:Depends}, php-i18nv2, php-mdb2-driver-mysql,
         php-text-password, dbconfig-common
Description: database-driven software for forms
 IntraHealth Informatics Core Engine (I2CE) is a set of classes for handling
 database-driven HTML forms with templates and database
 abstraction. It is the core programming engine for the iHRIS Suite of
 software.

The first stanza describes the source package and build depends. Items like Section and Maintainer will be applied to the later binary package stanza's.

Since each of the packages (at present) creates only one debian package, there is only a single Package stanza. If a source tree can produce multiple packages, then more stanzas will be placed here. Of course, the packaging becomes more complex, but since the IntraHealth packages don't use this, I've not covered it here.

copyright

Every Debian package must contain a copyright file so that users can easily find the license on the package. Since we're using the GPLv3, we can just make a reference to it. For an example of a more complex copyright file, see virtualbox-ose's copyright file in Ubuntu.

patches

The patches directory contains the patches for dpatch. The contents are described in the [#dpatch dpatch] section above.

config

This is a script that is included in the binary package and executed to take care of the configuration step of package installation. The only IntraHealth package that includes a config script is the i2ce package. i2ce uses this script to call the configuration hooks for dbcommon-config.

postinst

This script is included in the binary package and executed after the files from the package have been put in place. Any final setup takes place here. For example, i2ce uses this script to set some environment variables and then call the dbconfig-common postinst hooks:

dbc_generate_include=php:/etc/i2ce/i2ce.php.inc
dbc_generate_include_owner=www-data
dbc_generate_include_perms=0400
dbc_dbtypes=mysql

. /usr/share/debconf/confmodule
. /usr/share/dbconfig-common/dpkg/postinst

dbc_go i2ce $@

Any files that are under the control of ucf ([#ucf see above]) are handled here. i2ce installs its configuration file here:

ucf /usr/share/ihris/I2CE_config.inc.php /etc/i2ce/I2CE_config.inc.php

postrm

postrm is executed after the package has been removed. In the case of i2ce, dbconfig-common recommends deleting the files it generates during removal.

README.Debian

This contains any notes the packager may wish to include. Don't just copy a README file as the packaging usually includes this.