On 2015-06-15 20:38:25, Joachim Breitner wrote:
> 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.
Indeed! Thanks for starting this discussion.
> 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.
In general, I believe that storing upstream code in git is better for reasons
beyond packaging ease (e.g. authoritative deltas between upstream
orig.tar.gz as they were uploaded in Debian, reproduction of arbitrary
past versions, etc.), but I kind of agree that for mass packaging it's
better to not do that.
That said, I'd prefer if at least the repository records a checksum of
the upstream archive, since I feel this "checkout git signed tags but
use unsigned upstream archive from hackage" is not safe enough. Anyway,
another discussion.
> 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)".
Personally, for a long while I'm using fully qualified tag names, after
being burned during project merges due to tag conflicts. So I would
welcome this change, actually :)
> I’d prefer C over B over A. How about you?
While the myrepos suggestion is interesting, I also prefer C > B > A.
The rationale is that without upstream sources in git, each individual
repository is small enough that the overhead of "many" repositories will
be much higher than the network/disk saving of being able to checkout
only one repository. Plus, git partial checkouts.
And furthermore, C is the logical way if we want to scale our packaging
efforts.
thanks again,
iustin
Attachment:
signature.asc
Description: Digital signature