From Fedora Project Wiki
m (dependency info)
Line 26: Line 26:
%global debug_package  %{nil}
%global debug_package  %{nil}
</pre>
</pre>


== Dependencies ==
== Dependencies ==
 
Most of the golang-* packages are source code only, the *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes. ''(without single or double quotes)''
BuildRequires:
Binary builds that include these imports will use BuildRequires:
<pre>
BuildRequires: golang(github.com/gorilla/context)
</pre>


= Packaging Libraries =
= Packaging Libraries =
Line 42: Line 44:
== Dependencies ==
== Dependencies ==


To match the fully qualified import paths of the projects and source, utilize the meta wrapper in the golang namespace to provide the import paths being packaged.  
To match the fully qualified import paths of the projects and source, utilize the meta wrapper / virtual provides in the golang namespace to provide the import paths being packaged.  
 
Most of the golang-* packages are source code only, the *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes. ''(without single or double quotes)''
<pre>
Provides: golang(github.com/gorilla/context)
</pre>
 
Then other source packages that reference these imports can have Requires: matching that:
<pre>
Requires: golang(github.com/gorilla/context)
</pre>


'''TODO''': golang('github.com/gorilla/context')
Requires:





Revision as of 19:15, 14 October 2013

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Go Packaging Guidelines

Naming

Package Names

The package name idiom for the golang is that the import paths of libraries are fully qualified domain names. This way you have clarity to the precise upstream being used. We'll acknowledge this qualified path in the Provides, but also the package name should indicate the upstream project as much as possible. Truncating domain names and using '-' instead of '/'. For example, 'github.com/gorilla/context' would be 'golang-github-gorilla-mux' for the base RPM name. Similarly, the 'code.google.com/p/go.net' repository would be 'golang-googlecode-net' base RPM name.

Versions

Many Go libraries do not use package versions or have regular releases, and are instead maintained in public version control. In this case, follow the standard Fedora version conventions. This means that often Go packages will have a version number of "0" and a release number like "0.10.git27435c6".

Packaging Binaries

Some applications (like Docker) simply happen to be written in Go and are not meant to be developed against (they do not offer a Go language API). These should be named after the upstream project, and do not need a "golang" prefix or an import path added to the name.'

Since the golang compiler only produces static binaries, all golang binary packages have an automatic exception to the standard policy. The GCC Go compiler can produce dynamically-linked binaries, but at this stage in the language maturity it is important to use the reference compiler.

Debuginfo and Stripping Binaries

Fedora's debuginfo system currently does not work on Go binaries. Additionally, stripped binaries may cause crashes and are officially not supported. Therefore, do not strip binaries and use

%global debug_package   %{nil}

Dependencies

Most of the golang-* packages are source code only, the *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes. (without single or double quotes) Binary builds that include these imports will use BuildRequires:

BuildRequires: golang(github.com/gorilla/context)

Packaging Libraries

Go libraries packaged in Fedora are primarily for the purpose of building Fedora binary RPMs, and not meant to be developed against otherwise -- for that, we encourage the upstream "go get" idiom and a per-user $GOPATH. Specifically not to have a system wide GOPATH that users should inherit. This is to avoid custom workflows that developers are expected to learn, just to develop on this distribution. Also, by not landing source into GOROOT, the golang standard library stays pure and developers do not need to be concerned with library path conflicts, but instead can choose to include the system path in their per-user path (e.g. export GOPATH=$HOME/go:/usr/share/gocode). This way a call to go get ... would land new source in the $HOME/go directory

The standard golang compiler only produces static libraries. There is little value in shipping these prebuilt, especially since these libraries are very specifically tied to the exact minor release of the golang compiler. Instead, each library package should consist of a -devel subpackage which installs .go source code to /usr/share/gocode/src, under the appropriate import path.

Binary packages which build against this source will set $GOPATH to /usr/share/gocode or better '%{_datadir}/gocode'

Dependencies

To match the fully qualified import paths of the projects and source, utilize the meta wrapper / virtual provides in the golang namespace to provide the import paths being packaged.

Most of the golang-* packages are source code only, the *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes. (without single or double quotes)

Provides: golang(github.com/gorilla/context)

Then other source packages that reference these imports can have Requires: matching that:

Requires: golang(github.com/gorilla/context)


Security in Go Language Packages

If there is a security issue in the standard Go library or in a library built into binary Go programs, all affected RPMs will need to be rebuilt.

In the event that a security issue is found in a library, all packages which have that library as a BuildRequires must be identified and rebuilt with the version and release of the fixed library added to the BuildRequires.


repoquery -q --disablerepo='*' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires golang-$WHATEVER-devel


Additionally, other golang-*-devel packages may directly require their own dependencies; check for such packages with

repoquery -q --disablerepo='*' --enablerepo=fedora --enablerepo=updates --enablerepo=updates-testing --whatrequires golang-$WHATEVER-devel

and, if any of the results are golang-*-devel RPMs, repeat the previous step to find packages which may have that as a BuildRequires.

Thanks

These guidelines are Fedora-specific but are intended to match Debian practice where that is reasonable.

Discussion

See Talk:PackagingDrafts/Go for discussion.