Comparing packaging workflows in Debian and beyond
My blog post yesterday about Debian's git packaging workflows was meant to help fill some gaps in the documentation of this process, one of the most significant being the diagram.
I was surprised to find that some people felt my post argues that distribution tarballs are a must-have or that separate repositories are the optimal solution. In fact, my post was more a reflection of how things are being done, and it is great to see contributions from Joey, Russ and Thomas proposing ways to integrate the workflow in a single repository and also raising questions about the future of tarballs. Some of the changes outlined by Russ only entered the tools after many people were already using the workflow I have described.
Given the rise of collaboration, through collab-maint and packaging teams, it is more important than ever that workflows and tools are easily understood and documented. This lets new contributors (including people new to Debian) jump in more quickly and with less risk of disruption. It would be great to see some of these latest ideas covered more thoroughly with diagrams and I'm happy for people to rip-off my dia source file for my own diagram and amend it as they please (under the generous terms of the GPL v3)
A look at other packaging systems
With the role of the tarball in people's sights, it's worth looking outside Debian for a moment:
- Android packaging is radically different. All packages have a single integer version number. The pretty version number displayed to the user is meaningless. Due to the continuously increasing integer version, and the way that database schemas are versioned, it is not really possible to even keep multiple release branches in a repository. For an example, see the version in the Lumicall AndroidManifest.xml and the database upgrade function. Google Play/Android Market makes no rules about how a project manages its code. f-droid, the open source market for apps, builds projects like Lumicall directly from git, it relies on them having an ant build file in the standard format generated by the SDK.
- OpenCSW does not keep upstream tarballs at all. They keep a single git repository for tracking all packages. Each package is built from a Makefile (sample), and their tool suite takes care of downloading the upstream sources (using a URL specified in the Makefile) and verifying against checksums tracked in the repository (sample). The common style of the Makefiles makes it very easy for somebody familiar with the tools to work on just about any of the packages, and anybody who knows how to write a Makefile can start quickly.
Of course, these are just a few examples. These days, software is distributed in many different ways, whether it is a runnable VM image or an embedded device implanted during surgery.