[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Best practices for “versioned” modules?



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!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Attachment: signature.asc
Description: PGP signature


Reply to: