On Thu, 11 Jun 2026, Robert Elz wrote:
that isn't "let us" but "require us to", as with per-file patches there's no way (in general) to just apply one of them at a time, they can all depend upon each other (a changed function signature, in a source file, or using an added field in a struct, needs a corresponding change in a header file, or using a new function needs an additional library, and hence changes to the Makefile).
A long long time ago pkgsrc had topical patches. patch-aa, patch-ab, etc. were applied in alphabetical order. IIUC, you could have patches that were cumulative, i.e. multiple ones for the same file. You could also have more than one patched file per patch.
(By the way, my memory is fuzzy, this may have been in OpenBSD ports, not pkgsrc, but the point stands.)
Personally, I am very happy that the current standard is to have exactly one patch file per file, named after the file it patches. I am against the sort of per-topic patches that you describe, because it makes it so much more difficult to rebase when you update the package to a new version.
Honestly, if you would like this kind of thing, then pkgsrc patches are the wrong medium. Create a VCS branch on top of the original sources, add your patches there (one commit per "topic"), then rebase when a new version comes in. This needs no new development from scratch. You can do it today, with git, hg, fossil or a similar tool.
-- Benny