Page MenuHomeFreeBSD

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

Authored by des on Sat, Dec 6, 5:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 31, 5:01 PM
Unknown Object (File)
Tue, Dec 23, 12:03 AM
Unknown Object (File)
Fri, Dec 19, 1:37 PM
Unknown Object (File)
Fri, Dec 19, 12:42 PM
Unknown Object (File)
Fri, Dec 19, 12:36 PM
Unknown Object (File)
Thu, Dec 18, 3:23 PM
Unknown Object (File)
Mon, Dec 15, 1:59 PM
Unknown Object (File)
Mon, Dec 15, 1:59 PM
Subscribers

Details

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

This also drops support for pinning to -devel. This is currently unused
and doesn't work as implemented; furthermore, the current -devel port is
wildly out of date and is expected to be removed rather than updated.

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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
91

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)

des marked an inline comment as done.Sun, Dec 14, 2:26 PM
This revision is now accepted and ready to land.Sun, Dec 14, 4:02 PM

One question: should go:1.24 just mean go:1.24+? Do we foresee any reason that go:1.24 should bring in 1.24 when GO_VERSION == 1.25? Or would that lead to confusion?

You two have completely flipped me on the correct approach, and I'm now all-in on go.mk bringing in the right version for FreeBSD.org, not go.dev. I'm now wondering whether + should be more than just an optional feature. What do you two think?

One question: should go:1.24 just mean go:1.24+? Do we foresee any reason that go:1.24 should bring in 1.24 when GO_VERSION == 1.25? Or would that lead to confusion?

You two have completely flipped me on the correct approach, and I'm now all-in on go.mk bringing in the right version for FreeBSD.org, not go.dev. I'm now wondering whether + should be more than just an optional feature. What do you two think?

There can be rare cases where the newer toolchain doesn't work, so it seems sensible to keep the syntax without a + around as an exact version match. That said, users should be encouraged to use lower bounds if at all possible.

In D54104#1238865, @fuz wrote:

One question: should go:1.24 just mean go:1.24+? Do we foresee any reason that go:1.24 should bring in 1.24 when GO_VERSION == 1.25? Or would that lead to confusion?

You two have completely flipped me on the correct approach, and I'm now all-in on go.mk bringing in the right version for FreeBSD.org, not go.dev. I'm now wondering whether + should be more than just an optional feature. What do you two think?

There can be rare cases where the newer toolchain doesn't work, so it seems sensible to keep the syntax without a + around as an exact version match. That said, users should be encouraged to use lower bounds if at all possible.

Sounds good to me. Then I’m also a +1 on this patch.