Why I don't like the Debian source package format
I'm about to start modifying an Ubuntu package to build a modified version, so I've been reminded of all of the reasons that I don't really like the way Debian source packages work (Ubuntu uses the Debian package format). To explain why, I need to start with a brief description of how Debian source packages are put together.
Like all source package formats, Debian source packages need to contain
the four essential things,
but they do it in an odd way. Source packages generally come in two
different forms; let us call these the distribution form, which is
what you download, and the working form, which is what you expand the
distribution form into. The distribution form of a Debian source
package has three components: a
.dsc file of basic metadata, one or
more bundles (usually one as a compressed tar archive) of the upstream
source code, and a bundle of Debian modifications that are applied on
top of it. The working form of Debian source packages is a directory
tree of the source code, which is created by unpacking the upstream
source code and then applying the Debian modifications to it; after
this, the source tree will have a
debian/ subdirectory with control
files that describe how to build and package the source.
The largest problem with this is that the working form of Debian source packages has the upstream source already modified. The upstream source is not patched as part of building the binary packages (well, mostly); the upstream source is patched the moment that you even look at the source package. A direct consequence of this is that the control files do not exist until after you have patched the upstream source, or at least they do not exist in any readily accessible format.
Now we get to the mess that is the bundle of Debian changes. Debian
source packages have two formats for this (or at least two dominant,
non-experimental formats); the changes can be either a single giant
patch file (which must include creating the
or a tarball with the Debian control files and a set of
patch files (cf). The
quilt-based format is sane, but it's the newer one. The giant patch file
format is the older one and still quite common, but there are two things
wrong with it.
The first thing wrong with it is that it's terrible as a format for modifications, especially for sysadmins who want to add a change to an existing Debian or Ubuntu package. Let me count the way:
- a single giant diff is hard to read, especially when it also includes
creating the control files in the
- a single giant diff smashes logically separate changes together into
one big mess.
- it's impossible to separate out your own changes so that you can easily apply them on top of the next Debian or Ubuntu package update; you're better off keeping diffs of your changes outside of the source package system and then (re)applying them by hand.
The second thing wrong with it is that all of its problems spawned a
bunch of workarounds, which basically use
quilt or something like
it in the debian control files to apply changes as the software is
built. The large scale consequence of this is unpredictability. When
you get and set up a Debian source package as a non-specialist, the
resulting source tree may or may not reflect the Debian modifications
and there is no single procedure that you can follow to make changes to
it (especially maintainable changes).
(A meta-consequence of the introduction of a new and radically different format is that there are plenty of guides on 'how to do things with Debian source packages' out there on the web that hasn't been updated to discuss the new format. This is again a problem for non-specialists, who don't know enough to know that the guide is incomplete until something goes wrong. Note that I am barely more than a non-specialist (and most of that is due to writing this entry).)
A smaller irritation but something that is symptomatic of how Debian
does things is how you change the build version of generated packages. A
normal, sane packaging system would have an explicit field for this in
metadata somewhere. In the Debian package format, the build version
is derived by implication: each entry in the Debian changelog for the
package (found in the
debian/ subdirectory) has a build version
attached to it, so the build system 'simply' finds the build version of
the top (most recent) changelog entry and uses that.
(On reflection, I've decided not to say anything about the
debian/rules file. I'm a non-expert in working with Debian source
packages and so I suspect that everything about it is much clearer and
more obvious to people who are Debian package building experts. Every
source package system involves a certain amount of arcana and doing the
actual compiling and so on is often where it's concentrated.)