[pkg-golang-devel] [pkg-go] Security support for packages written in Go
paultag at debian.org
Wed Apr 6 17:38:22 UTC 2016
I don't think B-U is the appropriate place for this. This means if we
didn't change anything in dh-golang, we'd need to binNMU the package before
we can decruft the sources that have a newer versions, dak side.
With an ftp hat on, I think that's not right. Having the entire build
closure in it would be useful, but B-U is also used by dak to keep sources
we still have binaries related to in the archive.
We could add it as some sort of binary control header, but that's also
annoying. Less annoying, though.
On Wed, Apr 6, 2016 at 1:33 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Tianon Gravi:
> > On 5 April 2016 at 14:47, Florian Weimer <fw at deneb.enyo.de> wrote:
> >> We currently need these intermediate dependencies to discover all the
> >> affected applications. So perhaps dh_golang needs to construct the
> >> transitive closure, instead of listing just immediate build
> >> dependencies. If we don't want to put this information into the
> >> Packages file, maybe we can keep it in the separate debuginfo
> >> packages.
> > It _should_ be possible to adjust dh_golang to use "go list" in order
> > to determine the exact full set of Go packages which the application
> > code depends on, and then use _that_ list to cross-reference the files
> > in /usr/share/gocode to get the real list of packages for Built-Using
> > ( haven't verified whether it's feasible for dh_golang to do this, but
> > it's pretty similar to how it's currently using "go list" to gather
> > the list of packages to actually build).
> Please also add the version of the dh-golang package, so that we know
> what to rebuild if there's a bug in the Built-Using generation.
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pkg-golang-devel