[Slackbuilds-users] The state of development/google-go-lang

[Andrew Clemons]

Hello,

On 2026-05-07 22:11:25 +0300, slackbuilds-users at slackbuilds.org wrote:
> A few days ago ollama released an update that requires google-go-lang 1.26.
> SBo only has version 1.25.9. I took a look at the SlackBuild and found that,
> first, it's not as trivial as changing VERSION for a new even major number,
> and second, the code is a mess. So I refactored it.
> 
> Well, first I just wrote my own[1] code, then I combined it with the
> existing SlackBuild[2]. Key points:
> 
> 1. Instead of having a section for every bootstrap version, I iterate
> through them as the steps are the same anyway. This also means that future
> updates are as easy as adjusting GO_BOOTSTRAP array and required versions
> below it.
> 
> 2. I don't see a point in building the entire bootstrap chain from scratch
> every time. The first time? Sure, this ensures there were no blobs used. But
> afterwards? You've already done that, so why not just use the version you
> already have to build the next one? This significantly reduces build time
> when upgrading versions. So my script detects the available go version and
> adjusts the bootstrap chain as needed, even removing it completely if the
> previously installed version of google-go-lang is recent enough.
> 
> My "detection" relies on the fact that Slackware's stock gcc-go package
> doesn't set GOROOT environment variable, while SBo's google-go-lang package
> does. Hopefully, it's enough. And if not, the script should still build the
> package using bootstrapping from scratch.
> 
> 3. I removed some obsolete code. Also, what is the point of `go install`
> command? I don't think there's a use case for installing shared libraries of
> the toolchin itself. Arch doesn't do it, Google doesn't do it, everything
> still seems to just work if you don't do it. So I'm thinking about removing
> that too, it'll help save a lot of space.
> 
> And about the SlackBuild's state. The currently listed maintainer is Vincent
> Batts. However, his last contribution was in 2023, and the script has been
> de-facto maintained by the admins ever since. To whom should I've written
> this whole passage of text? Since I don't know, I'm writing here.

Regarding 1 and 2:

This is mostly just a case of inertia - what started off a one bootstrap
of 1.19 so we could build 1.20 slowly crept into multiple bootstrap
versions as the months rolled by with no new stable and golang's 6 month
release cycle. When I added the 1.19 bootstrap to build 1.20, I did not
bother trying to detect if there was already a google-go-lang installed
just always bootstrapped to keep things simple with the idea once the
next stable was released, we'd just delete that block of the slackbuild
again and there'd be no other changes to make. It was not my build, so I
did not want to make sweeping changes. Now, as you've pointed out, with
more time passing, it's a right mess with 3 bootstraps to get 1.25
built. I did consider some time along the way adjusting it, but had
still hoped we could just snip out the bootstrap steps at the beginning
and leave everything else the same when the next stable release came,
but now that google-go-lang is in current, this script is only here to
keep us covered until then.

Which brings me to point 3 - I don't know the answer. It has been there
since 4f1f5818531. But considering google-go-lang has been added to
current, probably not worth changing this slackbuild here now.

I have a few things that use google-go-lang, hence I have been bumping
the version - I updated it for 1.26 last week, but I have not submitted
it yet because its quite disruptive for the weekly update, but I will
probably do it this week or next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260508/bc3626ce/attachment.asc>