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
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:
The tools assume all files in
debian/are good. There's no way to make debhelper not install a
debian/initscript, 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
debiandirectory. Effectively, debhelper, and (possibly) cdbs are the only tools with the problem currently.
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.
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
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
switch, to make debhelper commands not act on a given file in the
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