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