Re: pkgquilt

On Sat, Jun 13, 2026 at 03:16:47PM -0400, Greg Troxel wrote:
 > Reading this thread, it occurs to me that the quilt scheme is an
 > approach to deal with two situations which are both problematic:
 > 
 >   A) a fork being maintained in pkgsrc, because upstream is nonfunctional
 >   or won't take patches
 > 
 >   B) lots of patches that should have been upstreamed haven't been
 > 
 > 
 > and for solutions
 > 
 >   A) actually fork and package the fork
 > 
 >   B) follow our documented policy and send them upstream

Yes, it is, and no, that isn't always the best approach.

Right now, on the assumption that upstream is dead, comatose, or
hostile, there are three choices:

   - maintain patches in pkgsrc
   - maintain patchkits outside pkgsrc somewhere
   - do a fork, maintain it outside pkgsrc somewhere, post new distfiles

of which the first is by far the lightest weight and doesn't commit
any one person to becoming the new owner of the leaky plumbing. The
second and third require one person to take charge, and have a large
startup cost too. Then if that person runs out of time or gas the
fundamental problem reappears... except now there's a multiplicity of
upstreams that the next person needs to figure out how to reconcile.

I've done a fair amount of the second choice in the past (you know
that but other people here probably don't) and it really does have the
disadvantage that nobody else can work on the patchkit.

I've proposed a few times that we set up some version control space
for packages like this, using our own infrastructure such that any
developer can commit. That lets us do either the second or the third
choice without most of the drawbacks. Generally people like the idea,
but it doesn't ever actually happen because it would take a lot of
administration.

In the absence of that, or some other lower-friction solution, we're
going to continue to have packages with nontrivial patch sets.
Something like pkgquilt would make managing those patches much easier.

As I said in the original email, though, I'm not going to get to it in
the foreseeable future, so someone else would need to take it up.

-- 
David A. Holland
[email protected]