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

On Sun, 14 Jun 2026 at 18:18, Edgar Fuß <[email protected]> wrote:

> > 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.
> In my opinion, per-topic patches would much better match the "please upstream
> patches" rule. Patches fixing bashisms, Linuxisms etc. are often spread across
> several files. Sometimes, patches to one file fix different things that ought
> to be upstreamed as seperate issues. Upstream may release with one issue fixed
> and others not.
> Othoh, upstream patches (like fixes/enhancements not yet incorporated into a
> release) may also spread across different files (and not be available as a
> downloadable patch).

*this* is one of the biggest arguments for a pkgquilt like approach.
Where a package has had to be patched for multiple issues, overlapping
between files the sheer drudgery of working through the affected files
and splitting out the various changes into coherent patch sets can be
a significant discouragement to upstreaming.

It's unpleasant enough that this email triggered an almost visceral
reaction, and I only rarely have to do it (and tip my hat to those
that do it often)

David