[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switch to git after all?

Hi again,

the thread has ebbed away, so it seems that most opinions have been

No single voice was raised in favor of Darcs. Doesn’t surprise me :-)

But there were more calls for a standard packaging approach than I
expected. If I read it correctly, Erik liked my approach, Clint had no
opinion and Joey, Iustin, Michael (welcome on this list!) and Colin
spoke in favor of either git-buildpackag and git-dpm.

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).

One important question to ask when deciding what to put in VCS is „What
is the source?“ and leave out anything that is not the source. We all
frown upon adding generated files in the repository, for example.
Similarly, when coding, we rarely put dependencies in our VCS. If
anything, we add a reference to it, e.g. as a git-module, or in less
formal ways.

So what does „source“ mean in the context of Debian packaging? The
sources are the files that the maintainer creates, edits and fosters.
Obviously, these are the declarative files in debian/ (control,
changelog, watch, etc.). Due to historical reasons, this also includes
the non-declarative files, even if they are identical across packages
(rules). And, if present, it is the content of debian/patches.

That directory in particular is very enlightening. It is much more than
just a means to change the original tarball into the shape we need for
Debian: This transformation is semantically split into individual pieces
These are named, commented, possibly cross-referenced. They have an
individual history. The art of our maintenance work when changing
upstream sources (should that be necessary) is not the change itself
(which is usually just taken from upstream’s trac or somewhere else),
but rather the curating work around it.

So debian/patches is the preferred form of modification (opponents of
dpkg 3.0 may disagree here and can now probably skip to the end as
well :-)) and therefore need to be stored in VCS _as the versioned

(This rules out using debian/patches as git commits, as git is not very
good in tracking the history of a changing (i.e. rebasing) branch. It
does not let me ask git „what is the history of this patch“ or „who last
changed that line in the patch’s metadata“.)

Besides debian/ (which obviously should be in the VCS) we have the
content of the original tarball, and the content of the patched tarball.
I find the analogy to libraries and generated files convincing:
The original tarball should not be part of the VCS, because it is not my
work and not my source: It is an external resource required during the
build process, and therefore referenced in my sources (via debian/watch
and the version in debian/changelog) – like a library that I use in my
Also the patched content should not be part of the VCS, because it is
the product of a mechanical step, namely applying the patches to the
original source.

So from applying commonly accepted and proven best practices about the
use of VCS, I conclude that VCS’ing debian/ (and debian/ only) is a
sensible way to manage the Debian packaging of some piece of software.

Let me add two additional minor points:

 * My impression from git-buildpackage is that it is not just „using git
for Debian packaging“, but rather it is a separate software that happens
to be using git underneath – in a way similar to how git-annex is not
just git. For example it uses multiple branches (debian, upstream,
pristine-tar) to track one line of development – that is not plain git
any more. The fact that users of git-buildpackage need specialized clone
and pull commands supports that.
 * As far as I know we have the only packaging system where the
packaging appears to be part of the original source tree (in the form of
the debian/ directory), instead of a thing living separated and read
independently during the build. With that scheme, nobody would even
consider to combine the packaging repository with the contents of the
upstream tarballs, let alone upstream’s own VCS into one repository. For
an example, see http://pkgs.fedoraproject.org/cgit/ghc.git/tree/
But practically, debian/ contains the same information (metadata +
patches) these days; the placement of debian/ during the build can be
seen as a historical artifact.

→ End of Arguing ←

So what now? On the one hand I’m inclined to say „Those who do most of
the uploads either don’t care or prefer this way, so we stick to it.“ –
after all, that’s how Debian works.

On the other hand, maybe I’m wrong and I’m preventing more people to
join the Debian Haskell Group; maybe it would work better or more
effective that way, even if I were less effective or slightly annoyed. I
don’t want to appear to exercise some sense of ownership here.

Should I be expected to change a running system in a way that I’m not
convinced of? Probably not. 

Will I stand in the way if there is a consensus among contributors that
git-bp or git-dpm is the way to go, and if there are people who work on
migration and setting new processes? Certainly not – maybe it is time to
allow for fresh people; I have been involved in DHG for quite a while

We had a round of opinions of what everyone prefers for himself. What
I’d like to hear from you now is: What do you think is best for the
Debian and the DHG – the existing practices, or a more standard


Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: