Hi again, the thread has ebbed away, so it seems that most opinions have been expressed. 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 data_. (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 project. 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 now. 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 approach? Thanks, Joachim -- 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