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

Re: dh_golang fails because a package got completely disabled with tags

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 <zhsj@debian.org> wrote:

On Wed, Feb 20, 2019 at 8:13 PM Reinhard Tartler <siretart@gmail.com> 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.

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,

Reply to: