Re: pkgquilt

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

    Date:        Sat, 13 Jun 2026 19:19:16 +0000
    From:        David Holland <dholland-pkgtech%netbsd.org@localhost>
    Message-ID:  <ai2tNLSCupRJcvfG%netbsd.org@localhost>

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

Yes, of course, but pkgsrc infrastructure is also part of tech-pkg.

It would have helped if you had given some kind of actual (fictional)
worked example showing how things would actually be done, rather than
just hand waving.   It still might.

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

I'll comment on that below.

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

You mean like SCCS, RCS, CVS, ...   After all, no-one would ever have used
any of those for any non-trivial source trees.

  |  > I don't do much pkgsrc work,
  | Yes, clearly you haven't :-)

That's fair, I don't do much these days (I used to do a bit more, though
not as a developer, back in the NetBSD 3/4/5 days).

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

No, but I can't see how your scheme would improve that.   Sometimes
patches get removed because whoever is working on something there believes
that they are no longer needed.   I can't see how anything you proposed
would cause anything different.   Sometimes they get removed because the
developer has no way to test a change, and doesn't want to make untested
changes to the upstream version.  Same thing, I don't see how your proposal
helps.  Sometimes it is unintentional, something just getting forgotten,
maybe your scheme might help.

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

And this returns to the point above - when I am working on something
(no matter what I am attempting to achieve) if I encounter something
unrelated that also needs fixing, I simply fix it (that can be anything
from another bug spotted in the code, to something trivial like a white
space error, or a typo in a comment or message).   I find myself unable
to resist doing that (if I don't fix it when I see it, it will get forgotten)
but it also helps with finding whatever I'm really looking to find and
fix, as it is one less distraction every time I gaze at the source file.

If that kind of thing is spotted initially it can easily be fixed before
any real changes are made, but that often doesn't happen - these issues
seem to crop up when I am in the middle of writing updated code, and then
branch off to verify how the args to some function are actually used, or
what data type this field in this struct is - so by the time the other change
is made, the source file has a bunch of other changes (half done) in it
already.

If you hunt for and find changes I have made (to src/* not pkgsrc) you'll
find many examples of this, the cvs log entry tends to start with an
explanation of the change for the primary bug being fixed, and then after
that continue with "while here ..." and whatever other changes slipped into
the same update get a mention as well.

Occasionally I have tried to avoid doing that, but the method of doing that
(except in the rare case where inconsequential changes were found and fixed
before any substantial changes were made) is almost always to fix everything,
but then move the fixed version aside, and regenerate the original, and diff
the two.   Then I manually go through the various changes identified by the
diff, and decide what kind of change each is primarily a part of, and select
one (topic) change to apply first, delete all the diff segments that aren't
for that change, and apply what is left as a patch to the replaced original
file, and commit that.   Then diff again against the desired final version,
and repeat, until all the changes shown are part of one topic, at which point
those changes are applied, and committed, and all is done.

Note that when it it is done this way, it is only the final version that has
ever been tested, even compile tested (when compiling is relevant) usually.
The intermediate versions might work (I always hope they will) or they might
not, no-one really ever knows, as it is only the final version which ever
gets used in practice.   But it satisfies (in some sense) the desire for one
topic patches, which I agree in principle, are better, but, at least for
me, are more or less impossible to produce except in very simple cases.

As an example given, what I understand your proposal to be, let's assume
I am to update a package which currently has just 2 patches (it could be
1000, but I only need 2 for this example), I do it your way, get the
upstream sources, use the new tool to get the first patch, apply it as
best as is possible, and then work on adjusting what is needed for it
for the changed upstream sources.   While I am doing that (just like as
above) I see something else that needs fixing, and fix that as well.
As I said, I simply cannot resist doing that - and the fact that had I
waited for the next patch to be applied, that one would have fixed that
same issue is irrelevant, I haven't gotten to that patch yet, so I don't
know what it does.

As I said last time, all this can be handled with enough discipline, but
I know I don't have it, I don't see how some tool (any tool) can possibly
change that, and what's more, I suspect many other developers are the same.
It is hard to simply leave broken/wrong stuff for later, when it is so easy
to fix it now (finding the cause of bugs is hard sometimes, it is often much
simpler to fix them once found, especially the relatively simple ones).

kre

ps: as this would be a new tool, if ever developed, I don't see any
reason any "prior art" should govern the names of the sub-commands it
would use - they should be designed to be what is most meaningful for the
users of this tool, not what seemed to make sense to the designers of
some other tool, no matter how similar that one might seem to be.