[git-buildpackage] A gbp workflow question re pq & patches

[Guido Günther]

Hi,
On Tue, May 10, 2022 at 05:59:02PM -0500, Seamus de Mora wrote:
[..snip..]

> Q: In my gbp-created 'dhcpcd5' git repo - as it stands now - must I carry
> forward a "patching system", OR may I simply apply the current patches to
> the sources, and carry on without a "patching system". In other words, is
> it possible to have a Debian package in which all changes are handled via
> the mechanisms of 'git' rather than the mechanisms of a "patching
> system"?

In 3.0 (quilt) packages all patches must be inside `debian/patches`.
Maintaining this folder is what `gbp-pq` aims to simplify. See

  https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html#gbp.patches.workflow

how this works.

The 1.0 source format allows you to patch the main branch of your repo
directly but since the 3.0 (quilt) format is what Raspian uses I'd stick
to that system but you can change to 1.0 format for your personal use by
changing `debian/source/format`.

You can also hack around things like

   https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.special.sloppytarball.html

which allows you to patch things directly.

> If this is not an answer you feel you can give, I understand. However, your
> opinion on the question would still be very useful to me. I will pick some
> of these things up as I go along, but I must keep going to learn.

It's not a matter of opinion, it's how Debian packaging works (and hence
what gbp can use to build the Debian packages from git on top of
that). Gbp is not meant as a tool to give you a Debian package no matter
what (there's tools like fpm for that) but rather a tool that allows you
to use git for packaging for Distributions like Debian/Ubuntu/Raspian
archive hence adhering to Debian's source format conventions. I know
it's not easy to get all those things together as git is just another
layer on top of "regular" Debian packaging (which is complex on it's
own).

So it really depends on what your aim is: if you want to adhere to
packaging policies (so others can reuse your work safely (which is what
I understood you want to do)) you're on the right track, if you just
want to create a one off package then you might want to take short
cuts as linked to above (or just patching the unpacked source).

Cheers,
 -- Guido

> 
> Thank you for your patience,
> ~S