Re: NVidia ports overhaul

Tomoaki AOKI <[email protected]>
Newsgroups gmane.os.freebsd.devel.x11
Organization Junchoon corps
Message-ID <[email protected]>
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.)


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

Regards.

-- 
Tomoaki AOKI    <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.