Re: pkgquilt

On Thu, Jun 11, 2026 at 06:12:12PM +0700, Robert Elz wrote:
 > So I assumed that "patches/" would be relative to pkgsrc (as in a sibling
 > to mk doc ... and all the categories) and would hold per-topic patches
 > which would be applied to all of pkgsrc/*/* (somehow).

I have no idea why you would think that. This is tech-pkg, we maintain
packages, wrangling package patches is a large part of that.

 >   | and also let us carry per-topic instead of per-file patches
 > 
 > 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).

For packages with large or invasive patch sets, that is so. However,
for such packages, maintaining per-topic patches (given a way to work
on one at a time) is vastly easier than maintaining per-file patches.

If you don't believe that, consider that it lets you deal with all
issues of one type at once when working, and then move to a second
different concern only after you've finished with the first. It also
lets you think about any given change as one thing, describe it as one
patch comment, understand it by reading one patch, and deal with it
all at once, rather than having the pieces splattered across a couple
dozen patches and mingled with unrelated changes.

If you still don't believe that, imagine what a mess any nontrivial
source tree would be if its version control were one patch per file
instead of one patch per topic.

And if you still don't believe it, then maybe consider that I've done
a lot of this work over the years...

 > I don't do much pkgsrc work, compared to many others essentially 0,
 > but I do appreciate that the per-file patches are trivial to maintain.
 > One simply gets the source files into the form they need to be in,
 > then diff's each changed file against the original upstream copy, and
 > what comes out is the required patch for that file.

Yes, clearly you haven't :-)

You say "simply", but in practice it's a pain, and it's not an
accident that sometimes patches just get thrown away when updating.
(And then fixed problems come back to life and someone has to spend
time re-debugging them, and believe me it's not fun to waste an
afternoon fixing a problem with a package you depend on to discover
that you'd already fixed the exact same problem with nearly the exact
same patch two years ago, and somebody just blithely deleted the patch
while updating.)

The order issue is irrelevant, we've always had ordered application of
patches.

 > Further, generating them is not easy unless you have a very disciplined
 > approach to working - [...]

... providing that support is the _whole point_ of a patch queue scheme ...

 >   | Then when working one would do "pkgquilt push" to apply the next patch,
 > 
 > sounds as if it should be "next" not "push"
 > 
 >   | "pkgquilt pop" to unapply the current patch,
 > 
 > sounds as if it should be "undo" or "revert" not "pop"
 > 
 >   | "pkgquilt sync" to update the current patch, 
 > 
 > sounds as if it should be "update" not "sync".
 > 
 > Why the bizarre command names, when simple ones that say what they
 > mean could be used instead.

Clearly you're not aware of the prior art.

-- 
David A. Holland
[email protected]