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

[Raphaël Halimi]

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
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).

>> 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.

Thanks for your time.

Regards,

-- 
Raphaël Halimi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sigxcpu.org/pipermail/git-buildpackage/attachments/20181116/cc587d46/attachment-0001.sig>