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

[Guido Günther]

Hi,
On Fri, Nov 16, 2018 at 05:59:30PM +0100, Raphaël Halimi wrote:
> Le 16/11/2018 à 15:28, Guido Günther a écrit :
> > 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.
> 
> This makes things much clearer. I failed to realize that GitHub could be
> considered as an untrusted source. I thought that [1] implicitly meant
> that they could be trusted (although they do specify to sign the tarball
> only after verifying that it "contains exactly the same data as the git
> repository").
> 
> But, isn't the whole point of pristine-tar to ensure that the orig.gz
> tarball is bit-by-bit identical to the upstream one ? With the method

pristine-tar generates a bit identical tarball to something you feed to
it (by remembering the the binary delta to a given git ref). What you
feed to it (a tarball generated by github (a) or a tarball generated by
git-archive (b), gbp (c) or something else (d)) it does not care (or
know about). These tarballs (a,b,c,d) are not necessarily bit
identical. You as maintainer decide what you consider the blessed tarball.

> you're describing, it may be different (even if the contents is the
> same) than the one distributed on GitHub, which seems to contradict [2]
> (although I understand this is just a best practice, not a requirement
> from the Debian Policy). It does theoretically guarantee reproducible
> source packages, though.
> 
> [1] https://wiki.debian.org/Creating%20signed%20GitHub%20releases
> [2]
> https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#pristinesource
> 
> > Doing
> > 
> >     gbp clone --debian-branch=debian/master
> 
> Ah ! :)
> 
> You didn't specify to to add the "--debian-branch" option before. The
> point of the heuristic method I described in my first e-mail was to
> guess the Debian branch without having to specify the option, but I
> admit it may be overkill.
> 
> > gives me a correctly checked out debian branch. If you put
> > 
> > [DEFAULT]
> > debian-branch=debian/master
> > 
> > in your ~/.gbp.conf it becomes:
> > 
> >     gbp clone
> 
> Unfortunately, I can't do that, since most of the packages I work on
> (officially or for my own changes on my personal repository) have the
> "classic" branches names (master, upstream, pristine-tar).

Yeah, the lack of a common layout is problem. I'm happy to apply a patch
that tries harder to look for the debian branch.

> >> 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.
> 
> Agreed. I wouldn't do that just to save one or two steps in my workflow,
> but I said it in the sense that it's what the tools seem to expect.
> 
> In conclusion, I guess I'll stick with the three separated steps for
> downloading the tarball, committing it to the pristine-tar branch, and
> importing the changes in the Debian branch.

I'm happy to fold in patches that make this simpler. If you want to file
a bug (even with a patch) to make "gbp pristin-tar" aware of uscan that
would already be a start.

> Thanks for your time.

Thanks for taking the time explaining our workflow!
 -- Guido