Re: pkgsrc-wip: misc/DeepSeek-TUI renamed to misc/CodeWhale; editors/fresh 0.3.12

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

Benny Siegert <bsiegert%netbsd.org@localhost> writes:

> On Sat, 6 Jun 2026, Jonathan Perkin wrote:
>
>> This obviously needs to be clarified with respect to pkgsrc.  For
>> example if we have a package that has an important fix in their
>> upstream repository but hasn't made it to a release yet we usually
>> apply that patch to pkgsrc.  Are you saying that if upstream used an
>> LLM we can no longer apply that patch even if we didn't write it?
>> How is that effectively different from just using an upstream
>> tarball that includes the LLM patch?
>
> AIUI, this rule does not apply to patches. Patches are considered part
> of the code base that is being patched and thus under the same
> licence.

We have considered patches the be licensed under the upstream license,
and I think it makes sense not to object to cherry-picked upstream
patches because they are vibecoded.  I would not really want to cross
into novel LLM output in pkgsrc.

Patches are kind of funny because they are sort of pkgsrc authored but
also at least partly by upstream, and sometimes totally by upstream.

I would say

  Despite the general prohibition on LLM output being committed to TNF
  repositories (including pkgsrc and pkgsrc-wip), adding a patch from
  upstream (merged, pending PR, proposed in their communications
  channels) is acceptable.  (As always, cherry-picked patches should be
  attributed, but that's not special about LLMs.)

> What is not allowed (again, in my understanding of the rule) is using
> a coding agent for the pkgsrc files themselves (e.g. Makefiles). Since
> Chavdar is doing that, these packages are not allowed in pkgsrc
> itself.

That is my interpretation too.

And, I would say wip should have the same rules as pkgsrc.