Go packaging guidelines?
Daniel J Walsh
dwalsh at redhat.com
Tue Jan 21 14:14:21 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
>> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the devel