The second part is an archive (currently a tar archive) containing files and directories to be installed.
In the future binary packages may also contain other components, such as checksums and digital signatures.
In order to create a binary package you must make a directory tree
which contains all the files and directories you want to have in the
filesystem data part of the package. In Debian-format source packages
this directory is usually debian/tmp
, relative to the top of
the package's source tree.
They should have the locations (relative to the root of the directory tree you're constructing) ownerships and permissions which you want them to have on the system when they are installed.
With current versions of dpkg the uid/username and gid/groupname mappings for the users and groups being used should be the same on the system where the package is built and the one where it is installed.
You need to add one special directory to the root of the miniature
filesystem tree you're creating: DEBIAN. It should contain the
control information files, notably the binary package control file
(see The main control information file: control
, section 2.3).
The DEBIAN directory will not appear in the filesystem archive of the package, and so won't be installed by dpkg when the package is installed.
When you've prepared the package, you should invoke:
dpkg --build directory
This will build the package in directory
.deb
.
(dpkg knows that --build
is a dpkg-deb option, so it
invokes dpkg-deb with the same arguments to build the package.)
See the manpage dpkg-deb(8)
for details of how
to examine the contents of this newly-created file. You may find the
output of following commands enlightening:
dpkg-deb --info filename.deb dpkg-deb --contents filename.deb
It is possible to put other files in the package control area, but this is not generally a good idea (though they will largely be ignored).
Here is a brief list of the control info files supported by dpkg and a summary of what they're used for.
control
control
, section 2.3.
postinst
, preinst
, postrm
, prerm
It is very important to make these scripts itempotent.[2] This is so that if an error occurs, the user interrupts dpkg or some other unforeseen circumstance happens you don't leave the user with a badly-broken package.
The maintainer scripts are guaranteed to run with a controlling
terminal and can interact with the user. If they need to prompt for
passwords, do full-screen interaction or something similar you should
do these things to and from /dev/tty
, since dpkg will at
some point redirect scripts' standard input and output so that it can
log the installation process. Likewise, because these scripts may be
executed with standard output redirected into a pipe for logging
purposes, Perl scripts should set unbuffered output by setting
$|=1
so that the output is printed immediately rather than being
buffered.
Each script should return a zero exit status for success, or a nonzero one for failure.
conffiles
control
control
. It contains all the package's
`vital statistics'.
The binary package control files of packages built from Debian sources
are made by a special tool, dpkg-gencontrol, which reads
debian/control
and debian/changelog
to find the
information it needs. See Source packages, chapter 3 for more details.
The fields in binary package control files are:
Package
(mandatory)Version
(mandatory)
Architecture
(mandatory)[3]
Depends
, Provides
et al.Essential
Maintainer
Section
, Priority
Source
Description
A description of the syntax of control files and the purpose of these fields is available in Control files and their fields, chapter 4.