Hi, On Fri, Dec 25, 2020 at 9:01 PM Cyril Brulebois <[email protected]> wrote: > > Hi, > > Looking at updating golang-github-gin-gonic-gin, I'm getting slightly > mixed feelings. > > There are quite a number of packages that depend on it, but throwing > `ratt` at a prospective packages gave rather good results: 32 packages > built just fine, and only 3 got an FTBFS. I have yet to confirm my > findings, but it seems like at least 2 of them are already not building > in unstable, and the last 1 is riddled with RC bugs, so shouldn't be a > huge issue. I'll double check, but that seems rather good to me. > > > On the other hand, I'm seeing at least two packages which come with some > kind of “version”: > - golang-github-gin-gonic-gin's go.mod wants: > + github.com/go-playground/validator/v10 > - The prospective golang-github-go-playground-validator's go.mod wants: > + github.com/go-playground/assert/v2 > > Focussing on the first one, running `dh-make-golang make -type l` with > either of the following as parameter gives the same results: > - github.com/go-playground/validator > - github.com/go-playground/validator/v10 > > which are: > > Source: golang-github-go-playground-validator > XS-Go-Import-Path: github.com/go-playground/validator > > Package: golang-github-go-playground-validator-dev > > while its go.mod contains: > > module github.com/go-playground/validator/v10 > > I suppose I would be absolutely fine with having a “versionless” package > if I hadn't spotted the existing one before: > - golang-gopkg-go-playground-validator.v8-dev > > One could possibly run into issues though, as both could advertise the > same XS-Go-Import-Path (after all, dh-make-golang didn't include the > version there). In this specific case, the hosting site changed, so > there's no actual conflict. Oh, and the naming is slightly different too > (v8 came after a dot). > > Should I be adjusting metadata produced by dh-make-golang, turning this > into something like the following? > > Source: golang-github-go-playground-validator-v10 > XS-Go-Import-Path: github.com/go-playground/validator/10 > > Package: golang-github-go-playground-validator-v10-dev > > > And same question goes for the other package, which has the following > (again, right after `dh-make-golang make -type l`): > > Source: golang-github-go-playground-assert > XS-Go-Import-Path: github.com/go-playground/assert > > Package: golang-github-go-playground-assert-dev > > while its go.mod contains: > > module github.com/go-playground/assert/v2 > > > Grepping through various go.mod, I've spotted this in syncthing (that I > need to keep an eye on, to make sure it doesn't regress when updating > other packages): > > github.com/go-ldap/ldap/v3 > > while the binary package in its Build-Depends is just named > golang-github-go-ldap-ldap-dev… > > (There's also another similarly-named package, and Go-Import-Path > similarities got me confused a little, until I figured out that a > compatibility symlink was added: > <https://salsa.debian.org/go-team/packages/golang-github-go-ldap-ldap/-/commit/6f2be56c0d661dadeec7c1feba89d49115925151> > which explains why golang-github-go-ldap-ldap-dev still mentions > gopkg.in) > > > All in all, I'm not sure what to do next with those two > golang-github-go-playground-* packages. Help most appreciated! >
I think currently for the Go modules, there's no consensus yet, at least not in the tools(like dh-make-golang), or the team website/wiki. All the docs/tools are invented before Go modules. Reading https://go-team.pages.debian.net/packaging.html again, I think it says the package name is derived from the import path. So github.com/go-playground/assert/v2 shoule become golang-github-go-playground-assert-v2-dev. But I think I haven't followed this pattern myself :facepalm: eg I uploaded golang-mvdan-xurls-dev, but its import path is mvdan.cc/xurls/v2, so it indeed should be golang-mvdan-xurls-v2-dev. (More round trips to NEW queue but less breaks.) -- Shengjing Zhu
