per-topic patches (was: Re: suggestions for url2pkg and pkglint (was: Re: libreswan 4.7 for wip))

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Jun 15, 2022 at 07:14:06PM +0200, Roland Illig wrote:
 > > Also pkglint wanted the patch broken down into individual files.  Here
 > > the tweak was small so accommodating that requirement was easy but
 > > that isn't true in general.  What should happen when the change-set is
 > > more substantive?
 > 
 > That rule has been around for more than 20 years now, I don't know
 > whether it made sense at any point. For patch files that have the word
 > 'CVE' in their name I already skip the rule, as I don't see a point in
 > splitting these topic-based patches.
 > 
 > 20 years ago, the patch files were still named patch-aa, patch-ab, so
 > the names didn't tell anything about the purpose of the patch. At that
 > time, the rule may have made a bit of sense, to avoid patching a file
 > twice. Since several years, the filenames of patches reveal what file
 > they patch, making these collisions less likely.
 > 
 > But even if there are collisions, I don't see a problem with them. If
 > there are multiple patches for ./configure, the first may fix
 > portability issues with 'if [ $var == "value" ]', the next may fix the
 > location of some header files, and the third may patch the location for
 > manual pages.
 > 
 > I'm in favor of allowing per-topic patches as well. It would be up to
 > the package maintainer to keep the patches manageable.

So, I've been saying for ages now that we should move to per-topic
patches. The sticking point, AIUI, is that with per-file patches you
can regenerate the patchset by re-diffing all the files against their
corresponding *.orig files. That breaks as soon as more than one patch
touches the same file -- you lose too much information when the
patches are applied.

ISTM that the way to deal with this is to replace mkpatches with
something like quilt or hg mq. This would be an overall improvement in
its own right, I think, separately from enabling per-topic patches.
But someone has to do it, because it's all very pkgsrc-specific and
there are various complications that need to be sorted out and
interactions with the pkgsrc build workflow. It's not a project for a
pkgsrc beginner unfortunately.

The other thing is that for most packages most of the time there's
only one or maybe two patch topics -- one is "configure for pkgsrc"
and the other is basic elements of "fix broken build". There's an
argument that anything going further than that should really be
maintained separately as a distfile patchkit, at which point you can
use whatever favorite tools you like to track things and just post the
results for download. (The problem with this is that it becomes hard
to collaborate on the patchkits; but other steps could be taken to
address that.)

I don't know what the answer is. Partly it's "the status quo isn't
actually awful so nobody's all that motivated to work on it".

-- 
David A. Holland
dholland%netbsd.org@localhost