Nikolaus Rath <nikol...@rath.org> writes: > On Jan 03 2017, Russ Allbery <r...@debian.org> wrote:
>> Speaking as a Debian user who frequently has to apply local patches or >> produce local versions of Debian packages for my job (usually weird >> backports or bizarre local requirements), I cannot express to you how >> much I prefer a Debian source package with patches in debian/patches >> over a Git repository with patches as commits. > Yeah, but I was not talking about the strength of preferences but the > number of users that have them :-). Also, you happen to be a Debian > developer and are therefore already familiar with the Debian source > format... Sure, but my reasons for wanting this are pretty common ones, I think. Maybe it will help to show an example. Usually what I have to do (and I think this is a pretty common use case for anyone who customizes Debian packages) is that I need to start from a package from unstable (or at least newer than stable, or oldstable, or ancient Ubuntu, or whatever crap I'm having to work on), apply some local patches, and backport it. So I: 1. Start from the Debian Git repository and make my own branch. 2. Add some new patches for local shit, maybe remove some packages. 3. Hack up the packaging in horrible ways for weird local requirements. 4. Usually get rid of a bunch of stuff that doesn't work in a backport. All this is roughly equally easy with either patches applied or a separate tree of patches. Then, suppose there's a security release of the package I started with, which adds more patches. If I'm lucky, those upstream changes don't conflict with local changes, and then this continues to be equally easy either way. But what happens to me a lot is that they *do* conflict, or maybe the new upstream is a completely new version of the package (and then it's pretty much guaranteed to conflict). With a patch tree, I merge in the new Debian packaging tree, and I get new patches, some conflicts on patches I deleted (which I can just resolve by deleting), and maybe conflicts on patches I modified (worst case), which I generally resolve by deleting the patch entirely, switching to the patch-queue branch, and then carefully add back in the patch and fix whatever conflicts. Then I have to rebase my patches against the latest upstream, which may require a bit more Git work. With patches applied, I merge in the new Debian packaging tree, and I get conflicts all over the upstream source. The conflicts come from multiple different patches, some of the conflicts are from patches I backed out of that have been modified, and single files have merge conflicts from three or four different conceptual changes at the same time. The whole thing is a total disaster that takes hours to unwind. Now, git-dpm gives both, as I've found out in this thread, which is great, since that means I can basically throw away the patched tree and do my normal thing with the patches. But without having those separated patches, the whole thing is an utter nightmare. (And I say that from having done it several times.) None of this is unique to me or requires any deep knowledge of the Debian package format. It's that individual patches are a way easier unit to work with when resolving conflicts than a patched tree. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
