Re: Best approach to update Go packages with the version in the go import path
On Tue, Jun 9, 2020 at 3:41 PM Arnaud Rebillout
<arnaud.rebillout@collabora.com> wrote:
>
> Hello go team,
>
> I'm wondering about the best approach to take for modern Go packages
> that include the version in the Go path.
>
> As an example, gotest.tools, ie. the Debian package
> "golang-github-gotestyourself-gotest.tools-dev" [1].
>
> * current version in Debian is 2.x, and it goes by the Go import path
> "gotest.tools"
>
> * latest version upstream is 3.x, with the Go import path
> "gotest.tools/v3"
>
I think the problem is more complicated.
1. we are still using GOPATH
2. gotest.tools/v3 is a go module thing.
Let's look some examples.
golang-dbus-dev's version is 5.0.3-1, it has migrated to go module.
And it's import path declared in go.mod is github.com/godbus/dbus/v5.
But the source files are installed at
/usr/share/gocode/src/github.com/godbus/dbus/(no /v5).
However some packages still using github.com/godbus/dbus import path. See
https://codesearch.debian.net/search?q=github.com%2Fgodbus%2Fdbus+filetype%3Ago&literal=1&perpkg=1
And it seems there's no regression.
I'm very surprised to see it works magically.
I think the magic only happens when:
1. the package to be built has a go.mod file.
2. there's a /usr/share/gocode/src/github.com/godbus/dbus/go.mod file.
I find this magic when I build containerd/1.4 in exp.
See the patch https://sources.debian.org/src/containerd/1.4.0~beta1~ds1-1/debian/patches/0002-Add-go.mod-file.patch/
> I'd like to update the package in Debian to 3.x, here are my options:
>
> 1) just bump the package to latest. Problem: it will break any
> package that build-depend on it, due to the change in the Go import path.
>
> 2) introduce a new package that I will name
> "golang-github-gotestyourself-gotest.tools-v3-dev". Problem: this new
> package will have to go through the NEW queue again.
>
Option 3 is like what golang-dbus-dev has done.
No rename binary package and source package. No rename of file path in
/usr/share/gocode.
If the transition to go module is only import path, no API break. The
things will just wok magically.
However if there's API break. Then I'm in favor of option 2.
And it should be a new source and a new binary package. So the old and
new exist together.
> To me, option 2 is the most appealing, but also the most problematic. I
> mean, now that some Go packages have their major version in their path,
> we can package concurrent major versions of a same package in Debian,
> and that's an improvement. It will help us to solve the dependency hell
> in some cases I'm sure. For example, to build the latest version of
> docker.io, I actually need both version of gotest.tools, because some
> components of docker.io use the v2, and others use the v3. In this
> situation, having both versions of gotest.tools in the Debian archive
> helps a lot, and avoid painful patching.
>
> But on the other hand, if it means that every time a new major version
> of a Go package is released, it has to go through the NEW queue again...
> Sounds like a showstopper.
>
> What's your thoughts on that? Did some of you already tackled a similar
> issue? Are they other options apart from the two I mentioned here?
>
> Thanks,
>
> Arnaud
>
> [1]: https://salsa.debian.org/go-team/packages/gotest.tools
>
--
Shengjing Zhu
Reply to: