Re: Best practices for “versioned” modules?
Hi,
On Fri, Dec 25, 2020 at 9:01 PM Cyril Brulebois <cyril@debamax.com> 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
Reply to: