I know the stereotypes.  Developers suck at packaging.  We’re typecast as thinking ./configure && make && make install is good enough or that piping wget into sh is acceptable.  But there are plenty of Makefiles without a working uninstall target and there are plenty of malicious shell scripts waiting to be piped to your shell.  Good packaging is a thing of beauty.

Of course, even the beautiful things get old.  There are parts of the Debian packaging system that I don’t believe have much use anymore so the tools and workflows I’m about to advocate do not and probably will not support them.

conffiles control file

conffiles instructs the package manager to treat the files listed within specially, taking great care not to squash deviations from the packaged version.  The extra care is welcome from the central Debian archive and never needed elsewhere.  Sometimes I know enough about my target systems to package configuration files just like other files.  All other times, I use Puppet to intelligently manage the file across my entire installation.

Source packages

The concept make sense for the central Debian archive because of the great distance between your average open-source project and the associated Debian maintainer.  See Giving up on Ruby packaging to get a sense of the problem.  However, in the year 2011 when version control is not heretic but required, why endorse another way to ship source code around?  Source packages have been superseded by GitHub.  The argument gets even stronger when I’m both author and maintainer.  Rather than having binary packages, source packages, source package source, and source source (still here?), everything is reduced to a Git repository and make deb.

Debra builds Debian packages

Debra was released months ago so I’ll treat this as a brief review.  Debra is how I build packages.  It ends up calling dpkg-deb(1) just like you’d expect but handles the heavy lifting for you.  Three commands:

debra create foo control
# Put files in foo/
debra build foo foo_$VERSION_$ARCH.deb
debra destroy foo

Debra

Freight builds Debian archives

Freight replaces reprepro(1) with two shell scripts.  freight-add(1) manages a staging area, typically in /var/lib/freight where it maps repositories to sets of package filenames.  Packages may appear in more than one repository to, for example, distribute the same package to several Debian/Ubuntu releases.  freight-cache(1) manages the web server’s document root, typically /var/cache/freight.  There it creates the Release and Packages files, deals with GPG signing, and managed the various available architectures.

Freight uses hard links aggressively to drop old packages from the cache and use as little storage as possible.  (I’m mildly obsessed with hard links.)

freight add foo_0.0.0-1_all.deb apt/lucid apt/maverick
freight cache apt/lucid apt/maverick

That’s all it takes to publish a Debian archive.  Just BYO web server.

Freight

Pack it up

You don’t have to go through what I’ve heard described as a “two year hazing process” to become a Debian developer and understand The Right Way to make packages.  Think through the benefits they provide (if you need help, read Why Developers Should Care About System Packages) then get that make deb target ready.