On 12/5/25 07: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.
If a port has known security issues that are expected to not be fixed
then it should inform users building+installing by setting FORBIDDEN
appropriately so they are informed before installing it. Apparently its
documented that such an entry should also exist for software of high
risk that is by design and not actually a vulnerability.
An entry in the vuxml database is appropriate to inform users after
install that may have the old package on their system that they have a
vulnerability to consider. Removing a port due to vulnerabilities
without a vuxml entry may permit users to continue to keep the software
around and use it without being aware of its issues.
MOVED entries do not seem to get passed along to pkg on my system to
tell me that software I am using was removed and why so the software
gets left around until I manually read through a list of installed
version comparisons to see that it is orphaned.
That reminds me that it seems pkg should be informed of MOVED entries
fro when a package moves from one ports tree directory to another but
that too doesn't happen. I'd say bumping a version to update such a
record is not appropriate since a full program removal+reinstall to
update such metadata leads to unnecessary downtime and system load. Is
there a current way to have pkg inform users of relevant MOVED data and
if so, is it quiet by default other than to avoid full reinstalls?
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.
I admit I don't know anything of go related ports but think of this
problem in general as it happens for other dependencies including but
not limited to other compilers too. If there comes a time where a never
version is needed to build software, how do you propose that such a
version be stated as a correct approach without it being a wrong
approach? In the case of the go discussion, it sounds like at the very
least that a comment should be put near a restriction to describe the
reasoning+limits of the restriction anytime the restriction itself
cannot fully describe the limit in a precise way.
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] <mailto:[email protected]>
