I speculate that most of what we do for Debian squares with what others do for their respective distro. Thus, it should be possible to identify a conceptual workflow applicable to all distros, consolidate individual workflows on a per-package basis, and profit from each other. Jonathan let me have the after-afternoon-coffee slot of the Distro Summit for an impromptu discussion on the various workflows used by distros for packaging.
The discussion round was very short-notice and despite the announcement sent to the conference mailing list, only ten people showed up: two people familiar with Fedora, and ("versus") eight Debianites.
Regardless, I think the discussion was success- and fruitful. We were able to identify a one-to-one mapping between the Fedora and Debian workflows, even though we use different techniques:
- both distros separate original software ("orig tarball") from modifications made to fit the software in with the rest of the distro.
- Fedora keeps the
.specfile, which references the original tarball, alongside any patch files in a per-release directory in their CVS tree, e.g.
/glibc/rawhide. To obtain a source tree, the contributor checks out the CVS subtree, downloads the tarball (from their own cache so as to not be at the mercy of upstream) according to the
.specfile, and merges the two. There is a tool to automate this, obviously. This process is regularly executed to produce "source RPMs".
- Debian keeps the original tarball next to a
diff.gzfile on the mirrors, along with a
dscfile which refers to them both. Tools like
dgettake the URL to the
dscfile to download all three, then invoke
dpkg-sourceto unpack the tarball and apply the diff. Individual patch files are either stored in
./debian/patches/(and applied by the diff), or they don't exist (meaning that all modifications are concatenated in the
Many Debian package maintainers use version control systems to
./debian directory, and if patch files
are stored in
./debian/patches/, then Debian and
Fedora both store patch files in a version control repository,
which seems awful.
Just as I am only one of many who are experimenting with VCS-based workflows for Debian packaging, the Fedora people are also considering the use of version control for packaging. Unlike Fedora, who seem to try to standardise on bzr, I try to cater for the plethora of version control systems in use in Debian, anticipating the impossibility of standardising/converging on a single tool across the entire project.
Update: Toshio Kuratomi wrote in to tell that Fedora has not settled on bzr: "the things that have been tried have spanned most of the current major vcs's (darcs being the one exception due to it's not meeting our requirements for keeping history intact.)"
It seems that our two projects are both at the start of a new phase in packaging, a "paradigm shift". What better time could there be for us to listen to each other and come up with a workflow that works for both projects?
My suggestion currently centres around a common repository for each package across all (participating) distros, and feature branches. Specifically, given an upstream source tree, modifications made during packaging for a given distro fall into four categories:
- upstream changes, such as bug fixes in the original code, or simple things like manpage typos.
- (Linux) distro stuff, such as
init.dscripts or Linux-ifications, which upstream doesn't care about or doesn't want.
- .deb/.rpm-specific changes, like the
./debiandirectory or the
- distro-specific modifications, like policy compliance and the like.
Given a version control system with sufficient branching
support, I imagine having different namespaces for branches:
debian/*. Now, when building the
Debian package, I'd apply
in order, while my colleague from the Fedora project would apply
fedora/*, before calling the
build tools and uploading the package.
There are surely problems to be overcome. Pascal Hakim mentioned patch dependencies, and I can't necessarily say with a clear conscience that my workflow isn't too complicated to be unleashed into the public… yet. But if we find a conceptual workflow applicable to more than one distro, it should be possible to implement a higher-level tool to implement it.
Also, the above is basically patch maintenance, not the entire workflow. Bug tracking system integration is going to play a role, as well as other aspects of daily distro packaging. I'll leave those for future time.
For me, this is the start of a potentially fruitful cooperation and I hope that interested parties from other distros jump on. For now, I suggest my mailing list for discussion. You can also find some links on the Debian wiki.