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

Re: Standardizing the layout of git packaging repositories



Hi,

On Fri, 15 Aug 2014, Simon McVittie wrote:
> I've been hesitating on whether to ask this because it gets into
> questions of workflow and repo structure that are very much a matter of
> taste and don't have a single widely-declared-to-be-good answer, but I
> think one of the important questions is: what is actually on the vendor
> (e.g. Debian) branch?

I think we can answer this question without imposing the associated
workflow.

What's on the branch should be a directory where we can call
dpkg-buildpackage and have the build work.

I believe that most of the current workflows do respect this rule (except
for the case where you only store the debian directory).

> git-buildpackage --git-export, with only debian/ in git
> -------------------------------------------------------
> 
> It is possible to use git-buildpackage with --git-export (either
> explicitly, or configured in debian/gbp.conf) for packages that only
> keep debian/ in git. In this situation, the only possibility is to have
> patches *not* pre-applied, because there is nothing there to patch. This
> matches how teams like pkg-gnome have traditionally used svn.
> 
> I would strongly recommend having upstream source in git, not just
> debian/, with one exception: packages like openarena-data, which mostly
> contain giant binary files that cannot meaningfully be patched.

Are you sure that --git-export is the right option? It needs a treeish so
I would expect that it can only use something that is in the git
repository.

Looking at the doc it's --git-overlay that is the important option,
obviously you need to combine this with --git-export-dir=../build-area/
to mimick what svn-buildpackage does.

(FWIW I do use --git-export-dir=../build-area/ but not --git-overlay)

> git-dpm
> -------
> 
> git-dpm encourages the contents of the vendor branch to be "exactly the
> source that will be built, vendor patches *are* applied" and uses a
> relatively elaborate merging structure to avoid rebasing
> (<http://git-dpm.alioth.debian.org/>). I don't know whether .pc is
> typically present in the tree for 3.0 (quilt) packages or not, or
> whether users of git-dpm avoid 3.0 (quilt) format altogether.

I'm not a git-dpm user but I just tried. patches are applied but .pc
is not present. This means that you can't use quilt but you can
call dpkg-buildpackage and have it just work because dpkg-source
is smart enough to detect that patches are already applied.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


Reply to: