Hello,

I think it makes sense, looking at the number of impacted packages and from my experience working

in go, even if the contract is the same, sometimes it does break on minor.

One more thing, should I do it in two patches like this?

1. Add go 1.18 inheriting from 1.17, allowing people to use 1.18 sooner?

2. Move to the default Go to 1.18 with (define-public go go-1.17) and create the testing branch from that?

Thanks for the `refresh` tips.

On Sun, Apr 10, 2022 at 4:45 PM Ludovic Courtès <ludo@gnu.org> wrote:

Hi,

Pier-Hugues Pellerin <ph@heykimo.com> skribis:

> I am trying to update Go to 1.18, I do have a *working* patch that defines
> a package that inherits from 1.17 and that adjusts the inputs.

Nice!

> However, I have a few questions:
>
> 1. Is inheriting the way to do that? The package's build system appears to
> be the same from 1.17.
> 2. How can I rebuild dependents packages to ensure they are still building
> correctly?
> 3. Anything I should look into or test more for these kinds of packages?

You can define Go 1.18 inheriting from 1.17; that’ll allow us to have
both versions, and eventually we’ll remove the older one.

Note that, to actually migrate Go packages to 1.18, you’ll need to
additionally change this line:

(define-public go go-1.17)

‘guix refresh -l go@1.17’ shows the “contour” of the set of packages
that currently depend on Go 1.17. These are all the packages that need
to be rebuilt if you change the line above. Since that’s a lot of them,
we could set up a dedicated branch and have it built by ci.guix. We’d
merge it once problems have been resolved.

Does that make sense?

Thanks,
Ludo’.