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

[Guido Günther]

Hi,
On Fri, Nov 16, 2018 at 02:38:30PM +0100, Raphaël Halimi wrote:
> Hi Guido,
> 
> Thanks a lot for answering.
> 
> > 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?
> 
> That's what I'm doing. I wrote that, with my current workflow, "master"
> is the upstream branch, "debian/master" (or "debian/sid") is the Debian
> branch, and "pristine-tar", the pristine-tar branch.
> 
> I don't understand precisely what you mean by "1:1 committed to git".
> Isn't the upstream branch supposed to hold exactly the tarball content,
> since dpkg-source emits warnings when some files present in the tarball
> are not present after dh_clean ?

Yes and therefore there is no need to re-import that tarball (use gbp
import-orig).

> 
> In that case, yes, I want the tarball "1:1 committed to git" ; that's
> why I don't use autotools' "make dist" (which adds configure,
> aclocal.m4, Makefile.in, etc etc to the tarball) in favor of GitHub's
> tarballs.

That works as well. You just don't commit the tarball, that is don't use
"gbp import-orig".

> By the way, I thought that's how it's supposed to be done, since "dh
> build" runs "dh_autoreconf".

Yes.

> > 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.
> 
> Well, I admit I didn't know about "gbp pristine-tar" (I see in the
> change log that it was introduced one and a half year ago; I use gbp
> since much longer than that...), but it still needs the tarball to begin
> with, hence running "uscan" beforehand. If only "gbp pristine-tar" had a

or "gbp export-orig" as I wrote above.

> "--uscan" option like "gbp import-orig" does, it would effectively be
> very close to what I had in mind.

"gbp pristine-tar" needs the tarball but on disk. Where that tarball
comes does not matter (wget, gbp-export-orig, uscan).

> To be absolutely clear, allow me to specify that the project is **not**
> Debian-specific, hence the need to have the distribution-agnostic
> sources on the "master" branch, as expected by non-Debian people.

Yes, and as I wrote that's how I'm doing things as well, see e.g.

    https://github.com/agx/whatmaps

> So, here's a precise description of my current workflow:
> 
> 1/ Create my git repository, with my sources on the "master" branch
> 2/ Tag it (say v1.0)
> 2/ Push to GitHub, including the tag
> 3/ Fork a "debian/master" branch for the Debian packaging
> 4/ Commit the Debian directory
> 5/ Run "uscan --force-download" (the watch file does **not** have
> uupdate as a script)
> 6/ Run "pristine-tar commit ../tarball master" (or now, "gbp
> pristine-tar", but I fail to see how the result is different; by the
> way, the man page's examples don't mention the necessary "commit"
> command, although it's present in the synopsis)
> 7/ Run "gbp buildpackage"
> 
> On new upstream releases (after committing, tagging and pushing "master"):
> 
> 8/ Checkout "debian/master"
> 9/ Run "uscan" (without --force-download, since this time, the Debian
> version will be behind)
> 10/ Run "pristine-tar" or "gbp pristine-tar"
> 11/ Run "git merge <new tag>"
> 12/ Run "gbp dch ..."
> 13/ Run "gbp buildpackage"

Here's what I do for new releases:

    1.) git checkout debian/master
    2.) git merge <upstream-tag>
    [do the debian tweaking if necessary]n
    3.) gbp dch -R -a -- debian
    4.) gbp buildpackage --git-pristine-tar-commit --git-tag

If I want the github tarball I'd use uscan to download the tarball. The
upcoming "gbp import-ref" is supposed to make 2.) and 3.) one step with
optional filtering to make things dfsg clean (that's its main purpose).

So the main difference I see is that you rely on github to build the
tarball while I do that locally (during the gbp invocation). This also
allows me to sign exactly this tarball.

> Having a "--uscan" option in "gbp pristine-tar" would be useful, since
> it would allow one to merge steps 5 and 6 (or 9 and 10).

I'm not opposed to this but I'm not likely to write it since relying on
external parties to create the tarball is nothing I do.

> Moreover, having a "don't update upstream branch nor create an upstream
> tag" in "gbp import-orig" would be even more useful, since it would not
> only allow one to merge steps 5 and 6, but more importantly, steps 9, 10
> and 11 could also all be done in a single run (with the --uscan
> option).

As I said: IMHO you should not use "gbp import-orig".

> Regarding the "make 'gbp clone' work out of the box" part, despite your
> indications, I couldn't succeed. Maybe I missed something, but "gbp
> clone" still checks out only the "master" branch (falsely believing that
> it's the Debian branch) and the "pristine-tar" branch, letting the real
> Debian branch to be checked out manually.

Doing

    gbp clone --debian-branch=debian/master

gives me a correctly checked out debian branch. If you put

[DEFAULT]
debian-branch=debian/master

in your ~/.gbp.conf it becomes:

    gbp clone

> Or am I not supposed at all to have both upstream and Debian on the same
> Git repository ? I'm starting to believe that everything would be much
> simpler to have the GitHub repository to hold the upstream sources
> alone, and a separate repository (say on Salsa) to hold the Debian
> packaging branches named like gbp expects them.

This makes having debian and upstream match much harder imho.
 -- Guido