Introducing dpkg source format for git repositories

Bastian Blank - 19 December 2019

There is a large disagreement inside Debian on how a git repository used for Debian packages should look like. You just have to read debian-devel to get too much of it.

Some people prefer that the content of the repository looks like a "modern" (3.0) source package the Debian …

There is a large disagreement inside Debian on how a git repository used for Debian packages should look like. You just have to read debian-devel to get too much of it.

Some people prefer that the content of the repository looks like a "modern" (3.0) source package the Debian archive accepts. This means it includes upstream source and stuff in debian/patches that need to get applied first to have something usable. But by definition this concept is incompatible with a normal git workflow; e.g. you can't use cherry-pick of upstream patches, but need to convert it into a patch file either by hand or with another tool. It also can't use upstream test definitions using a CI without adopting it and patching source first.

Other people prefer to have a complete patched source available always. This allows for use of cherry-pick and all the other git concepts available. But due to the way our "modern" (3.0) source formats are definied, it is impossible to use those together. So everyone wanting to use this can only use ancient 1.0 source packages, which lack a lot of features like modern compression formats.

Some do stuff that is much more weird. Weird things like git-dpm, which is also incompatible with merges. But we can't save everyone.

I started working on bridging the gap between a proper git repository and modern Debian source package by building a source package from some special target in debian/rules. But people maybe rightfully complained that not be able to use dpkg-source got a big downside and needs a lot of documentation. To get this into proper shape, I'd like to introduce a new dpkg source format.

New source format

The package dpkg-source-gitarchive defines a new source format 3.0 (gitarchive). This format doesn't represent a real source package format, but uses a plain git repository as input to create a 3.0 (quilt) source package that the Debian archive accepts.

This software got some currently hardcoded expectations on how things look like:

  • The git tree must not contain debian/patches, instead all Debian patches are applied as git commits.
  • The file debian/source/format exists in the latest commit, not only in an uncommited file.
  • Original tarballs needs to be managed with pristine-lfs and must be compress using xz.
  • Tags for upstream sources called upstream/$version need to exist.

Implementing this as a dpkg source format allows for a better user experience. You can build a new source package both from the git repository and an existing source package by using dpkg-source/dpkg-buildpackage and don't need to use special tools. No special tools or special targets in debian/rules are needed to manage sources to be uploaded.

Open questions

  • Is it a good idea to implement a pretty specific set of requirements as dpkg source format and make it an interface?
  • Is enforcing a repository based handling of upstream tarballs, for now only with pristine-lfs a good idea?
  • Should it also handle debian version tags?

*edit: package name was changed from dpkg-format-gitarchive to dpkg-source-gitarchive.