Re: Best approach to update Go packages with the version in the go import path
Hi Arnaud,
On 09/06/2020 04:34, Arnaud Rebillout 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'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.
>
> 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?
FWIW we had the same situation while updating the prometheus package
with golang-gopkg-yaml.v2-dev and golang-gopkg-yaml.v3-dev. Since both
of them are still needed we have a separate package which matches the
second option you mentioned.
--
Lucas Kanashiro
Reply to: