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

Re: Best VCS layout for our packages?

Hi Joachim,

you wrote:
"It is not possible to check out just one package. But maybe        that is a good thing, for such a tightly coupled package set."


with git 1.7 and sparse checkout this seems to be possible.

Note: I don't care and I never tried it, but since you listed it as a disavantage, I wrote it there.

When you start from scratch it might be useful to enable such features (if users needs them of course)



Sent from Yahoo Mail on Android

From:"Joachim Breitner" <nomeata@debian.org>
Date:Mon, 15 Jun, 2015 at 20:38
Subject:Best VCS layout for our packages?


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

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?


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

Reply to: