On Tue, 11 Sep 2018 at 15:57, Arnaud Rebillout <
arnaud.rebill...@collabora.com> wrote:
> Package: dh-golang
> Version: 1.35
> Severity: normal
>
> Dear Maintainer,
>
> it's been reported lately that the Built-Using field in docker.io is
> incorrect [1].
>
> I started to investigate, but docker.io is a complicated package with
> some embedded libraries and a hell of a debian/rules, so it's not the
> best package to investigate this issue.
>
> Instead, I found a more suitable package that also exhibits the issue:
> notary [2]. This package has a simple debian/rule, and excludes the
> vendor directory entirely.
>
> So I built the latest version of this package (0.6.1~ds1-2 at the
> moment), and checked the resulting Built-Using. It turns out that the
> following libraries from Build-Depends are missing in Built-Using:
>
> - golang-github-cloudflare-cfssl-dev
> - golang-github-mattn-go-sqlite3-dev
> - golang-github-miekg-pkcs11-dev
>
> Let's take these packages one by one:
>
> ----
>
> * golang-github-miekg-pkcs11-dev
>
> This build dependency is optional. We need it because we build notary
> with the build tag 'pkcs11'. dh_golang is not aware of that, so I guess
> that's why it doesn't detect this dependency.
>
Hmm, that's a tricky one. I'm sure that we could make it possible for a
package to have dh_golang pass -tags pkcs11 to all the various go list
commands it invokes. Would be better to not have to have the package
maintainer remember to do this, but I'm not sure I see a sane way to do
that.
> * golang-github-cloudflare-cfssl-dev
>
> This dependency is needed for the testsuite only. If we don't have it,
> then there you go...
>
> # github.com/theupdateframework/notary/trustpinning
> src/
> github.com/theupdateframework/notary/trustpinning/certs_test.go:15:2: \
> cannot find package "github.com/cloudflare/cfssl/config" in any of
> ...
>
> Should such a dep be eligigle to Built-Using or not?
>
It should not. No part of a package that is only used in the test suite is
copied into the binary package, which is (was) the criteria for Built-Using.
(Actually I think the current dh_golang is still over-broad: we should only
be mentioning in {X-Go-,}Built-Using the packages that contain dependencies
of Go pakckages that build binaries, not all Go packages. But this is
likely to be minor I think)
> * golang-github-mattn-go-sqlite3-dev
>
> Similar to cloudflare: it's only needed for the testsuite.
>
Similar answer!
> ----
>
> As a sidenote, I also spent some time investigating this issue on the
> docker.io package, and there's probably other problems to be solved
> there.
>
> I'm wondering, couldn't we generate the Built-Using field by recursing
> on the Build-Depends? Wouldn't it be more generic and failproof?
>
It used to copy build-depends, but I don't think it recursed. I think this
would in practice have different rather than better failure modes.
Cheers,
mwh
> Best regards,
> Arnaud
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908055
> [2] https://salsa.debian.org/go-team/packages/notary
>
> ----
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dh-golang depends on:
> ii debhelper 11.3.5
> ii dpkg 1.19.0.5+b1
> ii libdpkg-perl 1.19.0.5
> ii perl 5.26.2-7
>
> dh-golang recommends no packages.
>
> dh-golang suggests no packages.
>
> -- no debconf information
>
>
