Re: pkgquilt

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 10 Jun 2026 22:04:33 +0000
    From:        David Holland <dholland-pkg%netbsd.org@localhost>
    Message-ID:  <ainfcfKa8RUPf9O8%netbsd.org@localhost>

  | Recent talk about LLM patches

I suspect that has nothing at all to do with your suggestion,
and would have been better not mentioned in your message at all.

Next, before I say any more, a request, please don't just read
a paragraph of my test and think "no no, not that at all" and
jump at the reply button to correct tings, as I know I am about
to go off on a tangent which is totally wrong .. I will fix it
later, but I think still needs doing.

  | Long ago I proposed something called pkgquilt, which was basically to
  | be quilt (aka patch queues) integrated into pkgsrc patches.

Sorry, probably before my time, or I ignored it, or have simply forgotten.
but this is the first I have seen of this suggestion (as it will be to
many others I suspect) so I am going to start with my immediate first
reaction.

  | The idea would be that you can apply one patch at a time while doing
  | maintenance work,

And that's where it started, as while I'm sure you know what you intended,
to me this immediately read as "maintenance work on pkgsrc", and

  | The scheme would basically be that the patch store is patches/ and the

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).

Needless to say that doesn't seem practical at all.

I eventually worked out that you meant "maintenance work on a package"
and that "patches/" is the already existing patches directory that all
packages that need it already have.

At this point you can decide to reply if I am wrong about that bit,
as none of what follows will make any sense, so there would be no
point reading further.

  | which would both ease updates considerably

Yes, I can see how that might help, but only if:

  | 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).

  | and save on patch administrative overhead.

And there you have lost me, as I don't believe that for a minute.

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.

This way the order in which the patches are applied is irrelevant, just
that all of them are.

Per topic patches on the other hand require strictly ordered application
(or might do) and each subsequent patch can need to be regenerated if
an earlier one needs any update (at least they all need to be checked).

Further, generating them is not easy unless you have a very disciplined
approach to working - when working on one issue, you can't just notice
another problem and fix it at the same time, or there gets to be the
need to disentangle the changes later, and assign each to its own topic
patch, also deciding which order the the fixes should be applied in,
when probably for 2 separate issues (though perhaps affecting the same
area of code) there is no logical reason for one to precede the other.

If you don't keep that discipline, the "per topic" patches rapidly
devolve into a random set of miscellaneous ordered parches, none of which
does any particular thing, just they need to be applied strictly in
order (each subsequent patch simply adds more changes to earlier ones).

Generaring a new patch that way is perhaps easier, as one simply
applies all the existing patches, make a copy of the world, make
the needed changes across the tree, then diff the copy to the result,
and you're done.

But overall lower overhead, I don't think so .. the obvious problem
is when upstream either picks up one of the changes, or fixes the same
issue in some other way, and so pkgsrc's patch for that issue needs to
be removed or updated, potentially requiring updates to all the pacthes
that follow - and it is only that easy of pkgsrc's handling of the issue
is all in one of the existing patches, rather then spread out over many
as it was gradually refined over time by developers just using the
easy way from the previous paragraph.

So, really, I don't think this suggestion works at all, as it really
does depend upon per-topic patches, and I don't think those are practical.

But if it were to gain legs, then

  | 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.

kre