Re: NVidia ports overhaul

On 6/22/26 5:56 AM, Tomoaki AOKI wrote:
> On Sun, 21 Jun 2026 21:28:39 -0700
> Kevin Bowling <[email protected]> wrote:
> 
>> On Sun, Jun 21, 2026 at 2:33 AM Gleb Popov <[email protected]> wrote:
>>>
>>> Hi Kevin and Tomoaki.
>>>
>>> I made a PR on GitHub that tries to improve nvidia-driver ports'
>>> state. Please take a look at it.
>>>
>>> https://github.com/freebsd/freebsd-ports/pull/545
>>
>> It looks nicer but (IMO) it wasn't challenging to keep up to date as
>> is so I will defer to Tomoaki who has been doing most of the updates
>> lately to see if he wants any changes or to inherit the patch stack.
> 
> (Additionally CC'ing Austin, too.)
> 
> Hi.
> 
> First of all, thanks for your interests and trials.
> Sorry, couldn't yet take enough time to look closely into it.
> And as I don't have an account on GitHub, so cannot work on there,
> at the same time, I'm not enough familiar with GitHub.
> 
> Currently, what I've already did is to download your changes
> as patch, with adding ".patch" to the URL you noted.
> Is this correct? It looks like simply combined (adding to tail
> of previous) patch that fails for dry-run but seemingly succeeds
> for actual run.
> 
> And applied it to plain ports tree that all local changes
> to be stashed, apply the downloaded patch, stash it, then,
> stash show to obtain merged single patch file.
> 
> If it's correct to obtain the final form of your proposal,
> I'll try to take time to look into it.
> 
> And as Kevin already commented, my current workflow is
> optimized for the current form of ports.
> 
> Also, I understand making slave (child) port to be easier
> to prune would help future deletion. But there can be
> trade-offs on maintainabilities.
> 
> As you may noticed, many of the conditionals are defining
> start or end only. Conditionals defining both start and
> end would be limited. So what I fear for now is that
> the splits could cause additional complexities on maintainance.
> 
> One good (bad for users of old GPUs) news is that all legacy
> branches except 580 are already EoL'ed upstream and needed
> to be pruned in the future, once driver tarballs become
> unavailable for downloading or never-to-be-fixed CVEs are
> released for the EoL'ed branches.
> 
>   https://nvidia.custhelp.com/app/answers/detail/a_id/3142
> 
> And although still buildable, 304 is reported NOT working for years
> as of upgrades of x11-servers/xorg-server (changes in protocols to
> communicate with drivers).
> 
>   https://forums.freebsd.org/threads/locking-nvidia-driver-against-upgrades.101642/#post-743954
> 
> 
> So maybe the intermediate solution (split EoL'ed branches
> only, keeping 580 and later to be kept as-is) could be
> a reasonable solution.
> 
> What comes in mind is that EoL of stable/14, which last supports i386,
> would be a chance to drop 304, 340 and 390 branches that has i386
> supports. (Maybe portmgr would drop i386 supports throughout
> the whole ports tree if we ourselves don't prior to it.)

I think we've gotten a good port organization and Tomoaki has
been keeping things up to date really nicely, so I'd hesitate
to change things without a really good reason. I do however
think it's a really good idea to prune the old ports as suggested
here. Both removing i386 ports and removing old ones such as 304
which are broken would be good IMO.

Thanks,	
	Austin

> 
> 
> Anyway, I'll take time to look into closer.
> Please be patient.
> 
> Regards.
>