On 2025-12-05 15:47, Adam Weinberger wrote:
Hi everyone,
I just scheduled 3/4 of our Go ports for removal, along with 75 ports.
I want to explain why, and what we should do about it.
TL;DR--75 ports need to try altering USES=go:1.2x -> USES=go, because
likely none of the ports actually need to be deleted!
This is going to cause a scramble up-front here, but it's for our own
good.
============================
Why are we deleting Go versions?
============================
Go supports only the latest two minors. All minors older than that
have known bugs and security holes that will never be fixed. Currently
we provide SIX minors, which frankly is irresponsible. I'm going to
start being aggressive about culling old Go versions.
Currently, these 75 ports (plus another 68 for go1.24, and 51 for
1.25) pin themselves to a Go version with
USES=go:1.23
This *almost always* stems from a misunderstanding:
********************************
When a go.mod says "go 1.23" that means it needs AT LEAST 1.23, *NOT*
a need to pin it to 1.23!
********************************
============================
FACT: 99% of Go ports do not need a version pin!
============================
Go added a major new feature back in 1.21 (IIRC) where new versions of
Go can build software targeting older versions, by restricting its
build features and quirks to emulate those of the target version. In
other words, go1.25 can happily build software written for go1.23.
Additionally, Go added support for building a FUTURE version. In other
words, go1.23 can happily build software written for go1.25! You may
see some builds that say "Downloading go-1.25"---this is the build
system doing the right thing, downloading and utilizing the newer stdlib.
============================
A port I maintain, or a port I care about, is scheduled for deletion.
What should I do?
============================
First and foremost, try a test build with the version specifier
removed. In other words, change:
USES= go:1.23
to
USES=. go
and
USES=. go:1.23,modules
to
USES=. go:modules
If it builds successfully, either commit it, or submit a PR, or at the
very least reach out to the Go team.
If it doesn't work, check for updates upstream! You can try pinning to
a newer version (ex. USES=go:1.24), but be aware that it will still
get deleted when go1.24 gets deleted.
This means that:
**********************************
Any port with a pinned version will last at most 1 year in the ports tree!
**********************************
Go releases two minors a year, so any version-pinned port will last
until two future minors, which is at most a year away.
============================
Can't we turn USES=go:1.23 or USES=go:1.23+ to mean >1.23?
============================
Not really. We really do need a way to pin versions for when a package
simply cannot build with a newer version, but most importantly, the
right approach to version pinning is not to do it in the first place.
If you have questions, concerns, or thoughts, please reach out to
[email protected] (or reply here).
I'll reach out to individual maintainers with this same information.
--
Adam Weinberger
[email protected]
Hi,
The issue with this approach is that it breaks dependency tracking and
expected behavior within in the ports repo, concerns which have been
brought up before [1]. Indirectly it also show yet again that we need to
have a sane deprecation policy within the tree. If port X doesn't build
with a supported "compiler" it either needs to be patched (preferably
upstream and the pulled in downstream) or it needs to go.
If you install GCC 14 you don't except it to download and use GCC 11
instead. While this might clash with Go(lang)'s idea of an ecosystem
that's how we package ports and how people expect ports to work.
Going with the information above why not patch go.mod on the fly to
match the current compiler version being used? If it breaks patch or
mark it as broken and move on.
Best regards,
Daniel
1: https://reviews.freebsd.org/D49906
