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 _______________________________________________ git-buildpackage mailing list [email protected] http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
