Re: per-topic or per-file patches (was: pkgquilt)

Am Mon, 15 Jun 2026 11:28:34 -0700
schrieb "Greg A. Woods" <[email protected]>:

> In the grander question of per-topic or per-file patches, I think there
> should normally only be one patch file per package.  Yes I'm mostly
> serious.  The repository overhead is enough to justify this,

The overhead argument does not really go in one or the other direction,
IMHO. You can have one topical patch spanning many files or one
per-file patch including many topics. The amount of patch files in the
repo should not differ much. Or even, my estimate would be in the
other direction: If there is an API change that needs adding a
function argument to each call, it could be 100 small per-file patches
or one patch file for the topic. When you have many per-topic patches
touching a considerable part of the code base multiple times in an
overlapping manner so that they would actually be more numerous than
keeping their changes in per-file patches, then it seems to me that you
already got a fork, effectively, and the relation with the upstream of
that package should be reconsidered.

> Otherwise I'd say per-topic patches would be best, and this definitely
> makes it easier to upstream fixes and cancel them once a new release
> deals with the issue,

THIS! We all agree that carrying many patches for long is bad and only
to be done if upstreaming fails/is not sensible. Any friction to the
upstreaming process should better not exist. And having to dissect
per-file patches into their different topics is friction, at the very
least, even if you eventually learn tools to help with that. I don't
know of an upstream who likes 'here is a bunch of patches to your files
that all fix a bunch of issues'. They (and I, myself, as upstream)
really like to know what changes are done for which purpose.

It is really frustrating to have pushed a change upstream, have it
accepted, and then having to go into pkgsrc and dissect file patches
that don't apply anymore to circumvent the upstreamed topic. Imagine
the bliss of just deleting the merged patch after reading release notes
and doing `bmake` that then just works, or only breaks if there is
adaptation needed in the remaining patches — not because your
encapsulated old work conflicts with itself.

With the per-file-patches, the danger of loosing unrelated changes when
editing them, or wrongly assuming that a patch did thing X, while it
also contained silent fixes for thing Y, and just deleting the file, is
very real. Having to repeatedly re-introduce fixes that others deleted
by accident is Sisyphean torture.

> but they can become a major headache to maintain,
> especially when _not_ using a fork to manage these changes.

The only easy thing about the current pkgsrc approach is that there is
only one patched final state to maintain. It's basically one diff of
dist vs. patched. Thinking a bit more along those lines … yes, isn't
the only real difference of per-file patches vs. one big patch per
package that the per-file patches could be per-topic patches by chance?
Other than that, it's just lumping changes together, with the detail of
the file sections of a patch file being spread out on disk or not — and
with the need to carefully keep descriptions of patches up to date,
repeating the same message in patches carrying bits of a topical change.

It has a long history, but apart from that, it is really weird for me
to see this discussion in pkgsrc at all. I only ever experienced
per-topic patches in Linux distros I worked with. It's what I expect,
so of course my view is coloured.

The prototypical patch is 03-fix-gccXY.patch that fixes some structural
issues regarding C syntax all around the place. You see the breakage,
you make that patch. You submit it upstream and hope to remove it on
the next update. This patch is usually unrelated and in happy
coexistence with some ancient 02-use-our-default.patch that tweaks a
setting for the distro. Those would be different files in the pkgsrc
scheme only by accident, and would only in that case, be no source of
unnecessary nuisance.

The current per-file patching is only simple if _not_ striving to
upstream changes. If you don't care about the structure and meaning of
changes. If upstream only does changes unrelated to the pkgsrc patches.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg