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
