Go packaging guidelines?
fweimer at redhat.com
Tue Jan 14 11:06:09 UTC 2014
On 01/13/2014 04:11 PM, H. Guémar wrote:
> there's a draft, i suggest that you start checking it.
A couple of questions and comments. I think overall, the approach works.
# Packaging Libraries
This does not mention libraries which use cgo. Should they be handled
the same way? What about additional C wrappers?
# Libraries and Arch
Is it really a good idea to hard-code the list of supported
architectures in spec files? Is there a way to avoid this?
# Security in Go Language Packages
The repoquery invocations for checking for affected programs are
incorrect because the archive may have evolved from the time the binary
Go program has been built and no longer reflect those dependencies. The
non-stripped nature of binaries should make it possible to see, based on
the binaries alone, which libraries were used to compile it.
On the other hand, I wonder if we should rebuild all dependent binary Go
programs each time any of the libraries used to build it change. This
ensure that we ship matching source code for the compiled binary, and it
causes any breakage sooner.
Florian Weimer / Red Hat Product Security Team
More information about the devel