Page MenuHomeFreeBSD

Uses/go.mk: Add support for requesting a minimum version
Needs ReviewPublic

Authored by des on Sat, Dec 6, 5:27 PM.
Tags
None
Referenced Files
F139417536: D54104.diff
Thu, Dec 11, 8:40 PM
Unknown Object (File)
Sat, Dec 6, 10:24 PM
Unknown Object (File)
Sat, Dec 6, 10:18 PM
Unknown Object (File)
Sat, Dec 6, 10:15 PM
Unknown Object (File)
Sat, Dec 6, 8:43 PM
Unknown Object (File)
Sat, Dec 6, 6:12 PM
Subscribers

Details

Reviewers
adamw
Group Reviewers
portmgr
Summary

This adds support for requesting a minimum Go version instead of an
exact one. If USES contains something like go:X.Y+, we walk the list
of valid Go versions backward and pick the first element that matches
either the requested version or the default version. Assuming the
list of valid versions is sorted semantically, this means we will
pick the requested version if it is newer than the default version,
and the default version otherwise.

This is somewhat imprecise, but it's hard to do better without a
comparison operator that understands semantic versioning, which bmake
lacks. Simply comparing versions lexicographically or numerically
would produce incorrect results, since e.g. 1.3 precedes 1.29 but is
both lexicographically and numerically larger.

Note that this new code automatically handles development versions
without having to include -devel in USES. For instance, setting
USES=go:1.26+ will select lang/go-devel right now, and lang/go126
once it is created and GO_VALID_VERSIONS is updated accordingly.

Note also that specifying a version that does not yet exist in the
ports tree will have the same effect as specifying a version that
has been retired: silently fall back to the default version.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 69102
Build 65985: arc lint + arc unit

Event Timeline

des requested review of this revision.Sat, Dec 6, 5:27 PM
des created this revision.

Could we yoink the logic from python.mk for this?

In D54104#1236117, @fuz wrote:

Could we yoink the logic from python.mk for this?

Not easily, it's hundreds of lines of code. This works.

Mk/Uses/go.mk
78

Can we remove support for -devel?

That port is vestigial and should eventually become a bsd.go.mk. It holds an incredibly ancient version and there’s no clear benefit to me in providing devel versions in the future.

It would be a mistake for users to select it, so I’d vote for removing the option entirely.

For instance, setting USES=go:1.26+ will select lang/go-devel right now, and lang/go126 once it is created and GO_VALID_VERSIONS is updated accordingly.

Should that select ${GO_DEFAULT} by default instead? ${GO_DEFAULT} should always be the lowest support version of Go, and I’m hesitant about using -devel versions (even if that port were updated) to make production packages.

What do you think?

I didn't look at what lang/go-devel actually contains, I just went by GO_VALID_VERSIONS and the existing logic which seems to suggest that lang/go-devel currently offers 1.26. I don't care if we remove it, but I suggest we settle this first, and let @ashish have a say.

Having thought about this since I first posted the patch, I'm now also inclined to make it an error to specify X.Y+ if X.Y is not listed in GO_VALID_VERSIONS, instead of defaulting to GO_DEFAULT. We can easily make it a policy that any port that has USES=go:X.Y+ when X.Y becomes the oldest supported version gets automatically converted to USES=go (easily scripted, takes only minutes to run, commit, and review whenever GO_VALID_VERSIONS is updated)