Re: Question about pkgsrc patches [omitted gnats ref]

[Greg Troxel <gdt%lexort.com@localhost>]

Ramiro Aceves <ea1abz%gmail.com@localhost> writes:

> El 8/10/25 a las 7:47, Ramiro Aceves escribió:
>> El 7/10/25 a las 20:20, wiz%NetBSD.org@localhost escribió:
>>> Synopsis: math/octave
>>>
>>> State-Changed-From-To: open->closed
>>> State-Changed-By: wiz%NetBSD.org@localhost
>>> State-Changed-When: Tue, 07 Oct 2025 18:20:39 +0000
>>> State-Changed-Why:
>>> Thanks for the debugging! I've added the patch to pkgsrc.

> I am just curious trying to understand how pkgsrc release works. For
> example, is this readline patch applied to pkgsrc-current only or will
> it by applied also to pkgsrc-2025Q3 branch and a new binary package
> will be released in the repositories? I am curious about that. For
> example, if the patch is not applied to 2025Q3 many people desiring to
> install Octave package will be in trouble for a couple of months until
> 2025Q4 arrives.

Any NetBSD developer can make a commit to pkgsrc-current to fix a bug
(or other improvements).  There is a formal process to apply changes
made to current to release branches in pkgsrc (and the same process to
apply changes to netbsd-{9,10,11}).

It's work to prepare a change for pullup, and it's work for someone to
do it, so typically it happens when a developer (often, not necessarily
the same one) thinks it is worth doing.

I view pkgsrc as source-first, with binaries for convenience, and often
bring these fixes into my personal copy of the branch for use.  But
that's mostly for server type systems, and I run pkgsrc-current on my
desktop, building everything from source.   The work of applying the
update is small; it's being sure enough that it won't break other people
that makes it too hard to submit a pullup.

You can simply check out pkgsrc-2025Q3, and apply that change to
octave, and build octave.  It's fine to mix binaries and source as long
as:

   the sources you are using are the same sources that were used to
   build the binary set

   the mk.conf contents are the same

and really it's ok if you go off that a little bit.  Setting an option
for one package is generally fine (but you might also have to build from
source things that depend on that changed package too).  Getting one
package from current is often fine too, but you might have to tweak
PLIST or something.

So:

  cvs -d rootpath co -r pkgsrc-2025Q3 pkgsrc
  cd math/octave
  cvs up -A
  make package-install

has a good chance of succeeding.   See the guide and web pages to find
the cvsroot.

(If you want to use git, you can cherry-pick the above commit instead.)