This tool allows the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and a pbuilder running on the same machine can be using Unstable for package builds.
15.2. Building your First Package
15.2.1. Meta-Packages or Fake Packages
Fake packages and meta-packages are similar, in that they are empty shells that only exist for the effects their meta-data have on the package handling stack.
The purpose of a fake package is to trick dpkg and apt into believing that some package is installed even though it's only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there's no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.
On the other hand, a meta-package exists mostly as a collection of dependencies, so that installing the meta-package will actually bring in a set of other packages in a single step.
Both these kinds of packages can be created by the equivs-control and equivs-build commands (in the equivs package). The equivs-control file command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name and the maintainer, its dependencies and its description. Other fields without a default value are optional and can be deleted. The Copyright, Changelog, Readme and Extra-Files fields are not standard fields in a Debian packages; they only make sense within the scope of equivs-build, and they will not be kept in the headers of the generated package.
Example 15.2. Header file of the libxml-libxml-perl fake package
Section: perl
Priority: optional
Standards-Version: 3.8.4
Package: libxml-libxml-perl
Version: 1.57-1
Maintainer: Raphael Hertzog <hertzog@debian.org>
Depends: libxml2 (>= 2.6.6)
Architecture: all
Description: Fake package - module manually installed in site_perl
This is a fake package to let the packaging system
believe that this Debian package is installed.
.
In fact, the package is not installed since a newer version
of the module has been manually compiled & installed in the
site_perl directory.
The next step is to generate the Debian package with the equivs-build file command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.
15.2.2. Simple File Archive
The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package.
→ http://www.debian.org/doc/maint-guide/
The first step is creating a falcot-data-1.0 directory to contain the target source package. The package will logically, be named falcot-data and bear the 1.0 version number. The administrator then places the document files in a data subdirectory. Then they invoke the dh_make command (from the dh-make package) to add files required by the package generation process, which will all be stored in a debian subdirectory:
$ cd falcot-data-1.0
$ dh_make --native
Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch or cdbs?
[s/i/m/l/k/n/b] i
Maintainer name : Raphael Hertzog
Email-Address : hertzog@debian.org
Date : Mon, 11 Apr 2011 15:11:36 +0200
Package Name : falcot-data
Version : 1.0
License : blank
Usind dpatch : no
Type of Package : Independent
Hit <enter> to confirm:
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the falcot-data Makefiles install into $DESTDIR and not in / .
$
The selected type of package (single binary) indicates that this source package will generate a single binary package depending on the architecture (Architecture: any). indep binary acts as a counterpart, and leads to a single binary package that is not dependent on the target architecture (Architecture: all). In this case, the latter choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.
The multiple binary type corresponds to a source package leading to several binary packages. A particular case, library, is useful for shared libraries, since they need to follow strict packaging rules. In a similar fashion, kernel module should be restricted to packages containing kernel modules. Finally, cdbs is a specific package build system; it is rather flexible, but it requires some amount of learning.
TIP Maintainer's name and email address
Most of the programs involved in package maintenance will look for your name and email address in the DEBFULLNAME and DEBEMAIL or EMAIL environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is bash, it's a simple matter of adding the following two lines in your ~/.bashrc and ~/.bash_profile files (you will obviously replace the values with more relevant ones!):
export EMAIL="hertzog@debian.org"
export DEBFULLNAME="Raphael Hertzog"
The dh_make command created a debian subdirectory with many files. Some are required, in particular rules, control, changelog and copyright. Files with the .ex extension are example files that can used by modifying them (and removing the extension) when appropriate. When they are not needed, removing them is recommended. The compat file should be kept, since it is required for the correct functioning of the debhelper suite of programs (all beginning with the dh_ prefix) used at various stages of the package build process.
The copyright file must contain information about the authors of the documents included in the package, and the related license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default changelog file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from unstable to internal is enough. The control file was also updated: the section has been changed to misc and the Homepage, Vcs-Git and Vcs-Browser fields were removed. The Depends fields was completed with iceweasel | www-browser so as to ensure the availability of a web browser able to display the documents in the package.