Thanks for explaining what’s going on here. I think this actually makes for a compelling case to add explicit build tag handling. I’m still of the opinion that upstream should ship software in such a state that build tags shouldn’t be necessary, but the existing way to specify build tags clearly doesn’t work correctly, so adding an explicit option to dh-golang sounds reasonable to me.
On Sun, Feb 24, 2019 at 6:04 PM Shengjing Zhu <[email protected]> wrote: > Hi, > > On Wed, Feb 20, 2019 at 8:13 PM Reinhard Tartler <[email protected]> > wrote: > > > > Hi Michael, > > > > I'm not sure if this constitutes a bug in dh_golang, so I'm writing here > first. I'm working on > https://salsa.debian.org/go-team/packages/golang-github-containers-image > which needs buildtags to avoid a dependency on ostree. > > > > I'm in contact with upstream and we agreed that this dependency in not > worth the trouble keeping we agreed that for Debian, the best way to > proceed would be to use the buildtag containers_image_ostree_stub which > disables the package "github.com/containers/image/ostree". > > > > As your recommendations in the other email thread, I've added the -tag > option to the dh_auto_build invocation. That appears to work fine. > > > > However, the package build fails at the invocation of dh_golang. If I > understand the utility correctly, it invokes "go list" two times: The first > time to identify the golang packages that needs to be installed into the > Debian package, and a second time to identify what files are involved? > (Sorry, Perl is not my forte, and I think some commentary in the source > code on the thinking behind the '$tmpl' and '$gofiletmpl' variables that > are being passed to "go list" would be very valuable). > > > > If I understand the control flow correctly, it is the 2nd invocation > that crashes with this error message: > > > > > > dh_golang -O--buildsystem=golang > > can't load package: obj-x86_64-linux-gnu/src/ > github.com/containers/image/ostree/ostree_src.go:21:2: cannot find > package "github.com/ostreedev/ostree-go/pkg/glibobject" in any of: > > /usr/lib/go-1.11/src/ > github.com/ostreedev/ostree-go/pkg/glibobject (from $GOROOT) > > /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/ > github.com/ostreedev/ostree-go/pkg/glibobject (from $GOPATH) > > can't load package: obj-x86_64-linux-gnu/src/ > github.com/containers/image/ostree/ostree_dest.go:29:2: cannot find > package "github.com/ostreedev/ostree-go/pkg/otbuiltin" in any of: > > /usr/lib/go-1.11/src/ > github.com/ostreedev/ostree-go/pkg/otbuiltin (from $GOROOT) > > /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/ > github.com/ostreedev/ostree-go/pkg/otbuiltin (from $GOPATH) > > dh_golang: go list -f '\ > > {{ .Dir }}/{{ index (or .GoFiles .CgoFiles .TestGoFiles .XTestGoFiles > .IgnoredGoFiles) 0 }}' returned exit code 1 > > make: *** [debian/rules:8: binary] Error 1 > > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess > returned exit status 2 > > > > > > I believe fixing this might require changes in dh_golang, but I'd really > appreciate your opinion on this. Maybe there is a simple(r) solution that I > may be overlooking? > > > > Thanks! > > > > It's the limitation of dh-golang. You can't pass `-tags` argument to > the phase when generating Built-Using substvar. > > I have met the same problem when I package containerd. (I want to use > `no_cri` tag). > > As a result, I just removed the file(which has !no_cri tag) in configure > phase. > > https://salsa.debian.org/go-team/packages/containerd/blob/9fe3ea16/debian/rules#L18 > > I think there's case to use non-default build tag. But I don't know > whether it's worth to add the complex of dh-golang. And I think this > is discussed in your another thread. > > > -- > Shengjing Zhu > > -- Best regards, Michael
