From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: [IMPROVEMENT] add dependency to devel/crush
To: David Uhden Collado <daviduhden@gmail.com>
Cc: kirill@korins.ky, ports@openbsd.org
Date: Wed, 30 Sep 2026 09:36:03 +0100

On 2026/09/29 17:57, David Uhden Collado wrote:
> Kirill A. Korinsky wrote:
> > On Tue, 29 Sep 2026 09:08:20 +0200,
> > Stuart Henderson <stu@spacehopper.org> wrote:
> > > 
> > > missing bump.
> > > 
> > > this change means that crush is no longer installable on some archs.
> > > 
> > 
> > This some probably arm and i386 only.
> > 
> > As far as I recall it is the only LLM cooding tool in our ports collection
> > which may work at arm and i386, and this is a reason why I never added that
> > dep than I touched that ports or suggestef to add when reviwed it the first
> > time.
> > 
> > But I not sure how does it usefull for anyone to have crush at architectures
> > which misses rg.
> > 
> 
> Hello,
> 
> Thanks, you're right. Making ripgrep an unconditional RUN_DEPENDS would
> unnecessarily make crush uninstallable on architectures where Rust, and
> therefore ripgrep, is unavailable.
> 
> I've changed the dependency to follow the ports "rust" property instead:
> 
> .include <bsd.port.arch.mk>
> .if ${PROPERTIES:Mrust}
> RUN_DEPENDS =       textproc/ripgrep
> .endif
> 
> This keeps the preferred upstream behavior on architectures where
> ripgrep is available: the grep and glob tools will use rg.
> 
> On armv7 and i386, crush remains installable without ripgrep and those
> tools use their existing pure-Go fallback instead. So adding ripgrep
> does not introduce a new architecture restriction or remove Crush's
> existing support for those architectures.
> 
> While revising the patch I also updated Crush from 0.96.1 to the small
> 0.97.1 update and regenerated modules.inc and distinfo for the new Go
> dependency set. Since the package version is changing, a REVISION bump
> is no longer necessary.
> 
> I also corrected the license information that was already present in
> the port. It was described as if FSL-1.1 and MIT were separate license
> choices, but upstream uses FSL-1.1-MIT.
> 
> FSL-1.1-MIT is a single license, not immediate dual licensing under FSL
> and MIT. The current release is initially covered by FSL 1.1, including
> its restriction on competing use, and each released version
> automatically becomes available under the MIT license two years after
> that version is published.
> 
> Updated patch attached.
> 
> Thanks,
> David.

that email is *way* longer than it needed to be :)

post-release: i am ok with adding the RDEP conditionally

for the license marker i'd make it clear by saying

# FSL-1.1 (no-compete terms), old versions become MIT after 2 years