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

[Raphaël Halimi]

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 ?

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.

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

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

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.

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"

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

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

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.

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.

> I'm cc'ing the gbp list since this might be of interest to others.
No problem, receiving more input regarding my current workflow (and the
flaws in it) cannot hurt.

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/1d5ad58a/attachment.sig>