Can you please show commands that are causing the problem that this change tries to solve? It feels like there should be a simpler solution.

This is basically a refactor to ease maintainances.

Currently, for x11/nvidia-driver and x11/linux-nvidia-libs which are master ports, has distinfo for itself and all legacy branches in single distinfo file.
This causes race on updating ports.
If the time anyone is working on any of legacy versions while another person is upgrading master ports for production branch, collision happenes as both want to update exactly same distinfo, even if each of the upgrades are quite trivial.

And for graphics/nvidia-drm-*-kmod, distinfo of them contains both from corresponding graphics/drm-*-kmod and from x11/nvidia-driver. So currently when graphics/drm-*-kmod and/or x11/nvidia-driver are upgraded, distinfo of corresponding graphics/nvidia-drm-*-kmod also needs to be "manually" updated.

With this updates, collisions happenes only when the upgrade is non-trivial and require Makefile[.common] of master port to be modified. And as this makes distinfo of graphics/nvidia-drm-*-kmod to be generated on-the-fly, so no more manual excessive updates are needed.

From the point of view with "fixes", current form of make update-distinfo defined in x11/nvidia-driver/Makefile.common has problem inserting excessive TIMESTAMP line.

Remaining problem that (maybe) cannot be solved is that neither make makesum nor make update-distinfo doesn't work as wanted.
The wanted behaviour for legacy versions having both amd64 and i386 is upgrade both at the same time, but at least for now, I cannot find the way to do so without excessive dependencies just for it.

I'm still baffled about what's the problem with all these distinfos. Decoupling nvidia-driver-XXX distinfos looks like a good idea to me, so maybe we should start with that?

Some general thoughts:

• If running make makesum for a port removes some important bits from the distinfo file, it can usually be easily fixed by running git add -p or git restore -p. Maybe this problem can be solved this way too.
• If we have a group of ports and bumping one of them requires refreshing distinfo of all others, then I'd go for a common custom makesum target that will recursively do make makesum on all other ports in a group. I can provide sample code if needed.

I'm fine with splitting out "auto-merged distinfo" part for graphics/nvidia-drm-*-kmod into another review.
But as it strongly depends on the remaining part of this review (splitting distinfos for legacy versions), I've opened this as a "merged" one.
Putting "Depends on" line pointing to this review in the summary newly splitted out one does the right thing, right?
Or should I wait for the remaining-here part in this review to be approved and landed prior to opening another review?

And what make makesum does harm is (basically) only for submitters, maintainers and/or committers only, as what it breaks is NOT used for local builds (distinfo for i386 is not used for amd64 builds). So anyone simply want to override version for local builds for the exact same host the builder (including simple make) is actually running are not affected at all. I'll add comments what should be done on next update (need at least rebasing, anyway).

If we have a group of ports and bumping one of them requires refreshing distinfo of all others, then I'd go for a common custom makesum target that will recursively do make makesum on all other ports in a group. I can provide sample code if needed.

For this approach, modifying to-be-deleted part of update-distinfo target would help, not yet actually investigated, though.

Why bump PORTREVISIONs? There should be no visible changes in the resulting package.

Also, there is something wrong with the patch:

 % fetch -o - 'https://reviews.freebsd.org/file/data/wgbce3dvbonnjw6fxp6w/PHID-FILE-fd6ngvobir3ertwu456k/D50142.diff' | git apply
-                                                       12 kB   48 MBps    00s
error: x11/linux-nvidia-libs-304/distinfo: No such file or directory
error: x11/linux-nvidia-libs-340/distinfo: No such file or directory
error: x11/linux-nvidia-libs-390/distinfo: No such file or directory
error: patch failed: x11/linux-nvidia-libs-470/distinfo:0
error: x11/linux-nvidia-libs-470/distinfo: patch does not apply
error: x11/nvidia-driver-304/distinfo: No such file or directory
error: x11/nvidia-driver-340/distinfo: No such file or directory
error: x11/nvidia-driver-390/distinfo: No such file or directory
error: x11/nvidia-driver-470/distinfo: No such file or directory

How did you generate it?

Why bump PORTREVISIONs? There should be no visible changes in the resulting package.

Because the structure of the ports itself is changed in non-trivial way.

How did you generate it?

Basically used git diff -U999999 with redirects.
But as I'm not using local branch (I'm not enough understanding how .git is maintained, so to avoid pollutions of logs, create hand-crafted local patch, apply into working directory /usr/ports/, testing, stash before pulling update and git stash apply' instead of creating branches), it doesn't handle newly added files that are NOT git add`ed.
So I'm adding newly added files from local patch, fix until Phabricator accepts the diff.

For local test before uploading to Phabricator, I'm trying gpatch -p1 -R -E --dry-run -i patchfile whether gpatch seemingly revert the locally-patched working directory sanely or not.

Because the structure of the ports itself is changed in non-trivial way.

Revisions are bumped when a package should be rebuilt. This is not the case here.

Basically used git diff -U999999 with redirects.
But as I'm not using local branch (I'm not enough understanding how .git is maintained, so to avoid pollutions of logs, create hand-crafted local patch

Plain git diff will show you only uncommitted changes. You should use at least git diff origin/main to get the real difference between your checkout and upstream's state. Or even better, take a time to learn git basics, it is pretty easy on the surface.