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

[Seamus de Mora]

Hello,

On Wed, May 11, 2022 at 2:23 AM Guido Günther <agx at sigxcpu.org> wrote:

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


That is a clear answer to my question - thank you. I suspected it was the
case, but I was already stumped as to the next step & decided I'd be
foolish to spend additional time on unnecessary tasks. And yes - I do wish
to adhere to package policy. I don't understand the policy, but I'll
postpone any debate until I've got a much better understanding. At this
rate, that will be some time off :)

All of that said, I want to make an initial commit and push to remote that
will yield exactly (functionally?) the same .deb package as is produced by
the current source package in the raspbian repo:

https://archive.raspberrypi.org/debian/pool/main/d/dhcpcd5/dhcpcd5_8.1.2-1+rpt5.dsc

My second commit will be the "fix" to 'dhcpcd' - the same fix I submitted
to the upstream source, and raspbian about a month ago.

I think that means I should now begin reading `gbp-pq` in earnest, and
follow up when questions arise.

Thank you,
~S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sigxcpu.org/pipermail/git-buildpackage/attachments/20220511/0350a223/attachment-0001.html>