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 [1]
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 [1]
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[2] and include the upstream source.
--
see shy jo
[1] Assume that "release" does whatever is necessary to make a
releasable debian package, including modifications to cruft in debian/
[2] Or more accurately, the same VCS that upstream uses.
But it's probably git.
Attachment:
signature.asc
Description: Digital signature