May 2020 - openSUSE Go - openSUSE Mailing Lists

[opensuse-go] Updated golang-org-x-net pulling in unwanted dependencies
by John Paul Adrian Glaubitz 06 Jun '20

06 Jun '20

Hi! After updating golang-org-x-net to the latest upstream version [1], I have run into the problem that the package pulls unwanted dependencies, in particular it's pulling in the Google Cloud Go Storage module when I try to build another package which build-depends on golang-org-x-net: > unresolvable: nothing provides golang(cloud.google.com/go/storage) needed by golang-org-x-net Looking at the golang-org-x-net package, the only location where I can see that module being pulled in is the h2demo module in http2/h2demo through its go.mod: > require ( > cloud.google.com/go v0.38.0 > go4.org v0.0.0-20190218023631-ce4c26f7be8e > golang.org/x/build v0.0.0-20190509182522-45de920fc22c > golang.org/x/crypto v0.0.0-20190424203555-c05e17bb3b2d > golang.org/x/net v0.0.0-20190502183928-7f726cade0ab > ) Since this is just a demo module, I can assume we can ignore it, can't we? What's the proper and clean way to disable the sub-module and get rid of the Google Cloud Go Storage module? Adrian > [1] https://build.opensuse.org/package/show/home:glaubitz:branches:devel:langua… -- To unsubscribe, e-mail: opensuse-go+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-go+owner(a)opensuse.org

2 1

[opensuse-go] Determining the proper name for a Go package
by John Paul Adrian Glaubitz 26 May '20

26 May '20

Hi! I have run into the situation multiple times where I wasn't sure what name to use for a Go package. In particular, I'm working on packaging Google's cloud packages for Go, one of them being the Google Cloud storage package [1]. The source is hosted on Github at [2]. I have created a package called golang-github-googleapis-google-cloud-go [3] which contains the storage module as a sub-module. However, this doesn't work and the other packages which depend on the Google Cloud storage module don't build - even when adding golang-github-googleapis-google-cloud-go to their BuildRequires. My question therefore is: What is the correct naming and packaging schmeme in this case? Do I create a separate package for each sub-module using the cloud.google.com/go/storage naming scheme? Or do I create a single golang-github-googleapis-google-cloud-go package and just add all the sub-modules it provides to "Provides:" in the spec file? Thanks, Adrian > [1] https://cloud.google.com/go/storage > [2] https://github.com/googleapis/google-cloud-go > [3] https://build.opensuse.org/package/show/home:glaubitz:branches:devel:langua… -- To unsubscribe, e-mail: opensuse-go+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-go+owner(a)opensuse.org

1 0

[opensuse-go] How to deal with hard-wired version dependencies?
by John Paul Adrian Glaubitz 19 May '20

19 May '20

Hi! I'm currently working on packaging various Go packages which are required as dependencies for the new Go-based GoogleCloudPlatform packages [1,2]. One of the problems that I am frequently running into when packaging Go software are hard-wired version dependencies. For example, building golang-github-pkg-sftp fails with [3] > [ 4s] + go install -v -p 4 -x -buildmode=pie github.com/pkg/sftp > [ 4s] # get https://proxy.golang.org/github.com/pkg/errors/@v/v0.8.1.mod > [ 4s] # get https://proxy.golang.org/github.com/kr/fs/@v/v0.1.0.mod > [ 4s] # get https://proxy.golang.org/github.com/stretchr/testify/@v/v1.4.0.mod > [ 4s] # get https://proxy.golang.org/golang.org/x/crypto/@v/v0.0.0-20200221231518-2aa60… > [ 4s] # get https://proxy.golang.org/golang.org/x/crypto/@v/v0.0.0-20200221231518-2aa60…: Get "https://proxy.golang.org/golang.org/x/crypto/@v/v0.0.0-20200221231518-2aa60…": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:42701->[::1]:53: read: connection refused > [ 4s] # get https://proxy.golang.org/github.com/pkg/errors/@v/v0.8.1.mod: Get "https://proxy.golang.org/github.com/pkg/errors/@v/v0.8.1.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:42701->[::1]:53: read: connection refused > [ 4s] # get https://proxy.golang.org/github.com/kr/fs/@v/v0.1.0.mod: Get "https://proxy.golang.org/github.com/kr/fs/@v/v0.1.0.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:42701->[::1]:53: read: connection refused > [ 4s] # get https://proxy.golang.org/github.com/stretchr/testify/@v/v1.4.0.mod: Get "https://proxy.golang.org/github.com/stretchr/testify/@v/v1.4.0.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:42701->[::1]:53: read: connection refused > [ 4s] go: github.com/kr/fs@v0.1.0: Get "https://proxy.golang.org/github.com/kr/fs/@v/v0.1.0.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:42701->[::1]:53: read: connection refused > [ 4s] error: Bad exit status from /var/tmp/rpm-tmp.Ypx3yR (%build) which is apparently the result golang-github-pkg-sftp requesting specific versions of its dependencies in its go.mod file: > module github.com/pkg/sftp > > go 1.12 > > require ( > github.com/kr/fs v0.1.0 > github.com/pkg/errors v0.8.1 > github.com/stretchr/testify v1.4.0 > golang.org/x/crypto v0.0.0-20200221231518-2aa609cf4a9d > ) These hard-wired version dependencies obviously with the versioning policies we have in a distribution - namely that we are providing on particular version only and hence cannot provide specific versions of a certain package in order to satisfy such dependency requirements. What is the best way to work around this problem? Should I just patch the go.mod file to remove the hard-wired version requirements or is there a better way? Adrian > [1] https://github.com/GoogleCloudPlatform/guest-agent > [2] https://github.com/GoogleCloudPlatform/guest-logging-go > [3] https://build.opensuse.org/package/show/home:glaubitz:branches:devel:langua… -- To unsubscribe, e-mail: opensuse-go+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-go+owner(a)opensuse.org

2 2