Hi,
eventually, we will have to migrate away from Darcs, I’m afraid. If
only that nobody can use his ignorance of darcs as an
excuse to do work
here :-). I’m sure some of you will be happy to hear that.
But this opens a new can of worms: What is the best git-based packaging
approach for us?
I would argue that we have uncommon needs. Most of our packages are
very simple (and can be made even simpler with the help of cabal
-debian/debdry), but often changes affect multiple packages (bumping of
haskell-devscripts dependency) and may only make sense together
(upgrading of dependency chains). So we should discuss what that means
for us. In particular, I wonder if we find a scheme where all
development happens in one git repository.
Also, there is the question of what should be in a packaging git
repository. I am a firm believer that the upstream code should _not_ be
tracked in a packaging repository, on the grounds that we create and
maintain the debian/ directory, and the debian directory only: The
version in
debian/changelog file and the debian/patches/ directory are
sufficient to produce the source package.
So I currently see three sensible variants:
A. One repo per package, debian/ files in repo root.
This is basically the status quo, simply converted to git.
B. One repo per package, debian directory in repo.
A small variation. This has the advantage that you can run
$ git clone ..../haskell-foo.git
$ cd haskell-foo
$ origtargz
and have a standard debian source directory, ready to run debuild or
quilt or whatever. A .gitignore file can be crafted that makes sure
that everything but "debian/" is ignored. Note that debcheckout
supports this as well.
C. One big repo, haskell-foo’s debian/ files in haskell-foo/debian/
Having one repo has various advantages:
* Most importantly, there is one commit per logical change, even
if it affects multiple packages.
* This also reduces noise on the commit mailing list.
* It is immediately clear which packages we have packaged.
* No need to annoyingly create remote repositories when you
package something new.
* In order to compare the repo state with the package plan, only
one repository has to be looked at, not 700.
* It becomes easier to enforce certain things with git hooks, as
they do not have to be set up for every repository.
* Git hooks (and maybe jenkins jobs) have a global view of the
packaging.
But there are also disadvantages:
* Slightly unusual, so needs explanation.
* It is not possible to check out just
one package. But maybe
that is a good thing, for such a tightly coupled package set.
* Some tools might need to be extended to support that well. For
example debcheckout would need to support a "subdirectory"
parameter in the url specified in Vcs-Git, similar to the
branch parameter.
* Tags needs to be qualified by the package name ("haskell
-foo/1.0-1" instead of "1.0-1"). This would need support in
debcommit, similar to how gbp supports --git-debian-tag which
can be set to "%(pkg)/%(version)".
I’d prefer C over B over A. How about you?
Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
JID:
nomeata@joachim-breitner.de |
http://people.debian.org/~nomeata