Joachim Breitner wrote: > I’d like to explain with a bit more detail why I prefer debian/-only > packaging. If you have read such arguing before, feel free to skip that > part (→ End of arguing). An interesting point of view, well elucidated. It may somewhat fall apart when you consider what is the source of individual lines of debian/patches. However, I don't really want to quibble about the definition of "source". I prefer to just think about the set of workflows that a given use of a vcs makes easy, and those it makes hard, and prefer the larger and more useful set of workflows. Keeping upstream source in the debian git repository allows me to use these workflows: * git commit -m 'support new ghc"; git send-email HEAD^ --to $author; release  The most basic git workflow there is. With many variants involving eg github pull requests and BTSs of course. * git fetch upstream; git cherry-pick $upstream_bugfix_commit; release  The other most basic git workflow for distribution packagers. * git import-orig orig.tar.gz; release Where "import-orig" can be any of several debian-specific programs that deal with the "combine this git repo with this new upstream tarball" problem in different ways. * dgit pull; dch "acking NMU"; release If unfamiliar with dgit, this allows pulling a NMU's changes into your package's git repository. The NMUer did not need to make any git commits; this sythesises a git commit from the changes uploaded in the NMU and its changelog. Those are most of the ones I care about (except for the all-packages planning workflow that I clearly need to integrate into my own). But I don't care only about my workflows, I care about maximising the chance that others can use their own preferred workflows, while using a VCS for collaboration. All the evidence I've seen suggests that the best way to do that is to use git and include the upstream source. -- see shy jo  Assume that "release" does whatever is necessary to make a releasable debian package, including modifications to cruft in debian/  Or more accurately, the same VCS that upstream uses. But it's probably git.
Description: Digital signature