== An overview of the Debian and RPM source package formats

This is a brief and jaundiced overview of the format of Debian and RPM
source packages, what the Debian and RPM package systems theoretically
use to generate the compiled binary packages that people actually
install. As usual, this applies to all distributions that use the Debian
_.deb_ package format or the Red Hat _.rpm_ package format, although
specific details vary.  Also, I'm going to simplify to the common case.

A source RPM contains a specfile, a source tarball, and some number of
patches. The specfile describes the package, names the source tarball
and the patches, and contains a script that configures and compiles the
binaries (I simplify). It can also contain scripts that will be run when
the binary package is installed, removed, upgraded, or a number of other
events.  Specfiles support a complicated system of text macros, macro
substitution, conditional 'execution' of portions of the specfile (which
may wind up [[omitting or including some patches NiceTrueTypeFonts]]),
and even more peculiar things; these are used to automate a lot of
standard parts of the package build process, such as configuring a
program that uses standard GNU autoconf.

There is no fixed layout of where all of these pieces go when a source
RPM is unpacked and built; it depends on your local configuration,
although [[some arrangements are more sensible than others RPMBuild]].

(Note that those RPM settings have probably gotten slightly broken since
2006, since they seem to now be doing slightly odd things for me. RPM
macros have a lot of magic in them.)

A Debian source package contains a description file, a source
tarball, and a patch. After unpacking the source tarball and
applying the patch, there must be a top level subdirectory called
_debian_. Files in this subdirectory are used to control the rest of
the build and packaging process; although [[a number are required
http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html]], the
most important one is _debian/rules_, which is the Makefile used to
build the package.

(Note that this subdirectory can contain lots of things besides the
Debian package building control files. For instance, if the Debian
package wants to run scripts when it's installed, removed, or so on, it
will usually store the scripts in _debian/_.)

Much like RPM specfiles and their macros, Debian rules files support
a complicated system of helper programs to do most of the actual
work.  A typical Debian _rules_ file cannot be fully understood without
knowing what these programs do (some of this can be deduced from
their names). Debian being Debian, I believe that there are several
generations and versions of these helper programs (and no doubt epic
flamewars have been fought over which ones to use when).

(Debian helper programs are better documented than RPM macros, for
various reasons. Or at least more conveniently documented, since
they have manpages.)

A Debian _rules_ file may or may not further patch the source in the
process of building it. One style of Debian package rolls both making
any necessary modifications to the package source code and creating
the contents of the _debian_ directory into the initial patch; another
uses the initial patch only to create the _debian_ directory and then,
RPM-like, applies a series of source patches from the _debian_ directory
during the build process. Determining which approach any particular
Debian package uses may require close attention to the _rules_ file,
although if there is a _debian/patches_ directory the odds are good that
this source package uses some version of RPM-like two stage patching.

(In the Debian way, there appear to be at least three different systems
for doing such patching, each somewhat different.)