[git-buildpackage] Question about a very specific gbp workflow

[Guido Günther]

Hi Raphaël,

On Thu, Nov 15, 2018 at 03:22:14PM +0100, Raphaël Halimi wrote:
> Hi,
> 
> I have a question about gbp.
> 
> I'd like to know if there is any "best practice" workflow for gbp in the
> specific case when one is both upstream and debian package maintainer.
> 
> I already asked this question on debian-mentors [1] - although in a
> different form - a couple of years ago, but despite a fair number of
> answers, I still have problems with my workflow.
> 
> Let's say that I have a project on GitHub. The "master" branch then
> conventionally holds the upstream sources. Then I create a
> "debian/master" branch to hold a copy of the upstream sources and the
> debian packaging files.
> 
> Now, the first problem encountered is with importing upstream tarballs
> to the pristine-tar branch.
> 
> Currently, I have to run "uscan" to get the pristine tarball as built by
> GitHub) and then run "pristine-tar ../<tarball> master" to import it in
> the pristine-tar branch. This is tedious, and error-prone.
> 
> This could be automatically done by "gbp import-orig --uscan", taking
> advantage of the branches names already configured in debian/gbp.conf,
> but this method has two problems: it complains about the tag already
> existing in the Git repository, and it tries to import the sources again
> in the upstream branch ("master" here).
> 
> The suggestion in [2] seems neat, but has two problems I'd like to
> avoid: the Git repository would be cluttered with two upstream branches,
> and two set of tags.
> 
> In your opinion, would it be reasonable/useful (I can't believe I'm the
> only person confronted to this problem) to have an option in "gbp
> import-orig" to only take care of the upstream tarball, and not update
> the upstream branch or add tags, but still use them to link histories
> thanks to the "--upstream-tag" and "--upstream-vcs-tag" options ?
> 
> Also, either with my current workflow or if "gbp import-orig" would
> provide such an option, there would still be a slight problem : unless I
> missed something, "gbp clone" only checks out the three "traditional"
> Debian packaging branches (master, upstream, and pristine-tar). For
> example, with my current workflow, someone using "gbp clone" on the
> GitHub repository would have to notice that the "master" branch lacks a
> debian/ directory, and manually checkout the debian/master branch.
> 
> Granted, in that case, "gbp clone" doesn't have a gbp.conf to tell it
> the name of the branches it has to checkout, but maybe a simple
> heuristic method (for example, "if the master branch lacks a debian/
> directory, look for a branch named debian, or debian/master, or
> debian/sid, or any branch name suggested by DEP14, check that its latest
> tag matches the latest one on master, and if this branch holds a
> debian/gbp.conf file, then read it and checkout the right branches).
> 
> I know that suggesting those changes would be much more polite with
> patches attached, but unfortunately, I'm really, really not at ease with
> Python.
> 
> Anyway, feel free to tell my what you think about those suggestions,
> even if you think they're dumb and/or too marginal to be useful for a
> significant number of users.

Are there any reasons why you don't just use master as your upstream
branch. Is it because you want the tarball 1:1 comitted to git?

If you do use master as your upstream no import is necessary. If you
want pristine-tar commits use --git-pristine-tar commit when building or
"gbp export-orig / gbp pristine-tar". This also makes "gbp clone" work
out of the box. This is what I'm doing for my projects.

Also have a look at the (unfinished) "gbp import-ref" in current git.

I'm cc'ing the gbp list since this might be of interest to others.

Hope this helps,
 -- Guido


> [1] https://lists.debian.org/debian-mentors/2016/04/msg00160.html
> [2] https://lists.debian.org/debian-mentors/2016/04/msg00165.html
> 
> Regards,
> 
> -- 
> Raphaël Halimi
>