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

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

Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:

> * On 2026-06-06 at 19:12 BST, Greg Troxel wrote:
>
>>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.)
>
> But a patch that is not yet accepted by upstream is *not* ok, even if
> upstream are LLM-friendly and would likely accept it?

Yeah, that is awkward.  I am trying to have a discussion to figure out
our consensus, not speaking ex cathedra of course.

Stepping back, and avoiding your reasonable question for a moment, we're
saying that in TNF work products, we're not ok with LLM code.  I think
that's a combination of copyright (trained on stolen data) and quality,
but I'm accepting it at face value and as reasonable.

On the other hand, we have a long history of packaging code with
licenses that aren't Free Software.  Patches to non-Free software are a
complicated case and I think we've just avoided it because usually they
are small.

I was trying to draw the line between "the greater upstream content" and
"work done in pkgsrc".

Looking back, I said "proposed in their communication channels", so that
a patch to LLM code sent to their bugtracker, mailing list, whatever,
would be viewed as belonging to the upstream world.  We're supposed to
do this anyway, for changes that logically belong usptream.

Fixes to the build when it's a matter of the pkgsrc way vs some other
way I see no issues with.

I think what is bothering me is that sometimes we have a practice of
maintaining a dead upstream in pkgsrc, and in that case I new patches to
LLM code (or LLM patches) don't seem ok.

Agreed this needs to be clearly written down.  But I don't agree that we
need to say "LLM patches ok" or "LLM patches not ok".