Re: git: 045bc7b726d0 - main - sysutils/gdu: Update to 5.32.0

Robert Clausecker <fuz_at_fuz.su> wrote on
Date: Sat, 13 Dec 2025 00:22:15 UTC :

> Am Sat, Dec 13, 2025 at 12:49:56AM +0100 schrieb Daniel Engberg:
> > On 2025-12-13 00:41, Dag-Erling Smørgrav wrote:
> > > Daniel Engberg <diizzy@FreeBSD.org> writes:
> > > > Dag-Erling Smørgrav <des@FreeBSD.org> writes:
> > > > > The correct solution _in this specific case_ is to remove the
> > > > > version number. Just use `go:modules` and nothing more.
> > > > That just hides the real issue. The more appropriate solution instead
> > > > of downloading random toolchains would be to remove toolchain [...]
> > > 
> > > No. There is no issue. This port builds fine with all supported Go
> > > versions and does not need a “more appropriate solution”. Just remove
> > > the version number. No random toolchain will be downloaded. This is
> > > how it's supposed to work.
> > > 
> > > DES
> > 
> > Until it silently breaks, you don't expect the GCC 13 port to download 14
> > and use that instead right?
> 
> A toolchain is only downloaded if the toolchain requested by the port is
> newer than the local toolchain. This will not the case with the default
> toolchain, so no breakage is to be expected.
> 
> That said, we should set GOTOOLCHAIN=local to avoid this possibility
> entirely.

I was curious about some of the wording that has
been used in the issue. I found that
https://go.dev/doc/go1compat reports:

QUOTE
It is intended that programs written to the Go 1
specification will continue to compile and run
correctly, unchanged, over the lifetime of that
specification. At some indefinite point, a Go 2
specification may arise, but until that time, Go
programs that work today should continue to work
even as future "point" releases of Go 1 arise
(Go 1.1, Go 1.2, etc.).

Compatibility is at the source level. Binary
compatibility for compiled packages is not
guaranteed between releases. After a point
release, Go source will need to be recompiled to
link against the new release.
END QUOTE

So compatibility is about compilability and having
an abstract semantic conformance preserved, --but
not about binary compatibility being preserved
in the process, if I read that correctly.

(Progressing some into Go 1.21+ Toolchain/Runtime
specifics being involved that were not
guaranteed properties prior to that . . .)

It would seem that a large driver for what
toolchain version to use for compilation would be
driven by the binary compatibility goals of the
various compiles, if there are any for the
specific context. That is not the same as what is
specified by the go directive in go.mod.

It appears that the go directive in go.mod
specifies the minimium version and can lead
to a newer toolchain version being used --but
the newer tool chain then targets preserving
older runtime behaviors to match what the go
directive indicates --while producing the newer
vintage of binary standard involved instead.

Sound right?


===
Mark Millard
marklmi at yahoo.com