In the grander question of per-topic or per-file patches, I think there should normally only be one patch file per package. Yes I'm mostly serious. The repository overhead is enough to justify this, and I don't think it is any more difficult to manage -- at least not when I've done it for any "private" package changes I've maintained. Otherwise I'd say per-topic patches would be best, and this definitely makes it easier to upstream fixes and cancel them once a new release deals with the issue, but they can become a major headache to maintain, especially when _not_ using a fork to manage these changes. I don't have experience using a "quilt" tool to help with this so I can't comment on whether such a tool would help or not. I don't like the idea of maintaining a separate fork and using it to create new alternative distfiles just for pkgsrc to use though. The whole idea of starting with the original third-party distfile, checking its integrity, and then independently patching it via mechanisms in pkgsrc conveys a much higher degree of trust, at least in my opinion. If one is going to go to the trouble of maintain a separate fork for the purpose of making pkgsrc patch management easier, then one combined patch file is all one needs and wants. At Mon, 15 Jun 2026 01:05:38 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: Subject: Re: pkgquilt > > Date: Sat, 13 Jun 2026 19:19:16 +0000 > From: David Holland <dholland-pkgtech%netbsd.org@localhost> > Message-ID: <ai2tNLSCupRJcvfG%netbsd.org@localhost> > > | 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. Indeed! I'm not sure CVS really belongs there, though of course in practice it ends up that way, even really with the "fix" to add a per-commit hash. > 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. I always do this as well. Sometimes too aggressively, but c'est la vi. And yet I have learned the hard way over time that almost nobody will ever accept a set of mixed changes like this. (I agree they are harder to review, but, again, c'est la vi.) > 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 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). And yet without such discipline the changes one makes in this way to third-party code are impossible to upstream. However there is indeed at least one tool that makes it easier way to manage separating commits for unrelated changes once a whole suite of changes have been made, at least when using Git. The tool I use is "magit" in Emacs. It makes it relatively trivial to scan through a set of all current diffs across all files and then to stage individual "hunks" to make a commit. Apparently there are other stand-alone tools that do this with Git too. Magit saves me many hours of work when it comes to making sure I can create a set of upstream-able changes with per-topic commits. I cannot really work with third-party code any more without the help of Magit (thus the reason I have a huge set of changes and fixes I would like to submit to NetBSD proper, and to the pkgsrc infrastructure as well, but I'm waiting patiently (increasingly less so) until I can use Git to track NetBSD directly). It does require using Git though.... The staging area concept is what makes it possible in a humanly manageable way. So, in terms of pkgsrc though this means forking the package into a Git repository, making all the changes, separating them into per-topic commits, and then generating per-topic patch files. Or one big patch file with a pointer to the fork for other maintainers to co-operate. Note that such forks are only really feasible as co-operative tools if one uses a public "forge", i.e. one where _anyone_ can create an account and "fork" the fork and create a "pull request" with another proposed change. There is of course still admin overhead to merge and manage those changes and to create the patch file(s) and merge them into pkgsrc, but I think it might be lower than the overhead of having per-file patches and having patches disappear for various reasons. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpyqT_ktShXf.pgp
Description: OpenPGP Digital Signature