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 ), 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 .

(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 , 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.)