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

[Alistair Crooks <alistaircrooks%gmail.com@localhost>]

Personal email, so personal opinions here :)

I think I view this differently to everyone here - pkgsrc infrastructure for me is the same as NetBSD base repos, and should be, and remain, LLM-free. Not because we know better, but my experience is that portability across each OS means avoiding GNU-only arguments or functionality in utilities, perl or python isn't ubiquitous, bash-isms hurt, cmake might have super green messages, but setting the right compiler flags consistently is super-painful; and LLMs aren't quite able to nuance all of those things yet. (I 'm writing this in June 2026, hello future pedants) Then there's the damage their crawlers do to pkgsrc infrastructure (see spz's points in the AGM), and the environmental harm, followed by licensing issues, and finally, as I came originally from Scotland, the rising cost of tokens, de-skilling of development, quality issues, and we'll ignore the bias amplification for now and keep this apolitical.

Here's where my views probably differ - Makefiles are, as Jonathan pointed out, template vehicles. Patches relate way more to original source trees than anything else. Text in DESCR files is usually taken from website or original READMEs. Buildlink files are templated as well. For me, not nearly as sacrosanct

On reflection, maybe this is what everyone else is saying?

As I said, my personal opinions, certainly not intended to be more than that 

On Sun, Jun 7, 2026 at 14:17 Greg Troxel <gdt%lexort.com@localhost> wrote:

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".