From time to time the question comes up on Debian mailing lists of whether debian directories in upstream tarballs are harmful and what do do about them. I tend hide from such threads, since all upstream tarballs I create contain debian directories.

But I realised tonight that the common wisdom from those discussions is wrong, or at least incomplete. Here's why.

First, it's important the notice that this is not a problem in the rpm world. Putting an rpm spec file in an upstream tarball is considered good practice. There's no downside; if a packager needs to change how the package is put together, they can replace the spec file. And users can run rpmbuild on the tarball and get an rpm spit out. Handy.

So, then, why is the equivilant practice a problem in the debian world? Three intertwined reasons:

1. The tools assume all files in debian/ are good. There's no way to make debhelper not install a debian/init script, or any similar file.

   Note that this problem only affects helper tools like debhelper; the core deb building tools only care about a few files that are in every debian directory. Effectively, debhelper, and (possibly) cdbs are the only tools with the problem currently.

2. The source package format doesn't support removing files from the upstream tarball. This is a pretty silly limitation that any source format better than the current one should override. If wig and pen was ever implemented, it should support some means of deleting files.

3. Package maintainers fear that they can't get upstream to make changes, or not fast enough, so worry about getting into a mess with files in an upstream debian/ that can't easily be fixed.

I feel that if any of these three problems is solved, an upstream debian directory is ok. #3 can be solved to some extent for some packages, though these solutions will always be the least satisfying.

It's tempting to try to solve #1 in debhelper. I could add an --ignore switch, to make debhelper commands not act on a given file in the debian directory. (Update: done in version 5.0.57!)

The best place to solve it, though, would be in the source package format. I'd be happy to see wig and pen be implemented, but would be happier to see us moving toward using a distributed revision control system as a source package format. Consider a source format that replaces .diff.gz with .git.tar.gz.

discussion