Go packaging guidelines?

Daniel J Walsh dwalsh at redhat.com
Tue Jan 21 14:14:21 UTC 2014

Hash: SHA1

On 01/14/2014 02:18 PM, Matthew Miller wrote:
> On Tue, Jan 14, 2014 at 12:06:09PM +0100, Florian Weimer wrote:
>> 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?
> I think for now, yes. Unless you have a better suggestion.
>> # 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.
> Hmmm, okay. Would it be useful to have a script that generates a list 
> automatically?
>> 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.
> I'm worried that that would cause a lot of needless churn. But maybe it's 
> for the best.
I have added some go bindings for libselinux, which are used in the docker
port.  Currently I am shipping these in libselinux-devel.

# rpm -q libselinux-devel

# rpm -ql libselinux-devel | grep go

Is the correct way for C libraries that we ship to provide go bindings?
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the devel mailing list