On Sat, Nov 20, 2021 at 5:00 PM Vipul Kumar <ku...@onenetbeyond.org> wrote: > > Hi, > > In debian/control file of "golang-github-oklog-ulid" package, > "XS-Go-Import-Path"[1] field has "github.com/oklog/ulid" as its value. > Shouldn't it be "github.com/oklog/ulid/v2"? Upstream[2] along with > packages[3] which require ulid package as its dependency, uses > "github.com/oklog/ulid/v2" as its import path. >
Since we don't use Go module, this doesn't matter too much. But AFAIK, those packages whose name has version number, have version number in XS-Go-Import-Path as well. For example: golang-github-urfave-cli-v2: github.com/urfave/cli/v2 > [1]: https://salsa.debian.org/go-team/packages/golang-github-oklog > ulid/-/blob/debian/sid/debian/control#L14 > [2]: https://github.com/oklog/ulid#install > [3]: https://gitlab.com/gitlab-org/labkit/blob/v1.10.0/go.mod#L15 > > I noticed, similar thing with some other packages: > > - golang-android-soong (android/soong) > No hostname present in import path. > This is correct, because upstream doesn't define it with hostname. https://android.googlesource.com/platform/build/soong/+/refs/heads/master/go.mod#1 > - json2file-go (https://salsa.debian.org/sto/json2file-go) > Import path contains protocol information (i.e. https://). > This is wrong. > - obfs4proxy (gitlab.com/yawning/obfs4.git) > - golang-goptlib (git.torproject.org/pluggable-transports/goptlib.git) > - snowflake (git.torproject.org/pluggable-transports/snowflake.git) > Import path contains ".git" suffix, but for all these three > import paths, "go get" command is working. Is it common practice to use > ".git" suffix in import path? Also, note that, all these three packages > are maintained under "Privacy Tools" group. Because upstream defines it with .git suffix. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/go.mod#L1 -- Shengjing Zhu
