DRAFT

====Main Package====

====Subpackages====

Every golang package should provide its source code in a *-devel subpackage.
Automatic script regularly checks corresponding build of devel subpackage and content of tarball for missing/superfluous parts.

As of now it checks devel subpackage for Provides, BuildRequires, Requires directives

One golang package can have more subpackages. For example google introduces new import equivalents, so code.golang.org/p/ is being replaced by golang.org/x/.
Thus temporarly additional subpackages can be presented. Devel subpackage is however renamed into golang-golangorg-....
Only devel subpackage of the original component's name is inspected (This can be change if .... some additional plugins/tests?).

Devel subackages are not allowed to contain executables.

golang-github-ogier-pflag


====naming convension====
code.google.com/p/go.text => golang-googlecode-text
github.com/jonboulle/clockwork => golang-github-jonboulle-clockwork
gopkg.in/check.v1 => golang-gopkg-check

====global macros====
At least the following macros must be presented in the spec file:
	%commit	- commit of the source codes - used to automatically detect packages/tarballs with outdated source codes
	%import_path - prefix of all import paths - for golang/googlecode, it can be detected but for http://godoc.org/speter.net/go/exp/math/dec/inf, it is too specific

%global %debug_package %{nil} - if the package is not buildable, no debug

====import_path====
- how to automatically detect an import path of a subpackage?
github.com -> github_import_path
code.google.com -> googlecode_import_path
golang.org -> golangorg_import_path
gopkg.in -> gopkg_import_path
- more import paths in one subpackage or unknown repos?
- I guess more like a configuration file in gofed tool
- some packages are specific (more versions, more import paths, ...)

====devel====
Every subpackage which provides source codes:
- must have all Provides in a form golang(import_path/...).
- its name must end with '-devel' sufix
- non source codes packages must not end with '-devel' sufix
- every subpackage should contain only one import path (not enforced)

Every devel subpackage has at least one source tarball.
Only devel subpackages can be checked againts their tarballs. What about the rest?
Maybe some mapping (two or more packages origin from the same tarball => they should have the same Provides just with a different prefix).
When a devel subpackage has more import paths assigned (with one source)? How to check this? Maybe for lated? :)

====detections====
What can be detected and from what source
- executables:	build
- Provides:	build	(all possible Provides from tarball)
- BuildReq:	build	(all possible BuildReq from tarball)
- Requires:	build	(all possible Requires from tarball)

====hints====
- package name is not so important as to provides
- packages should use 'golang(...)' [Build]Requires and does not rely on package name

====Provides of import paths====
1) Complete list of Provides
	+ Intuitive for a developer
	+ All used import paths can be queried (independent of any tools used to scan used import paths)

	- With each update I have to modify the list (we have gofed inspect -p + grep to filter out incorrent import paths)
	- Harder to automize it (gofed inspect -p + grep)

	Anyway this is not an issue, all used import paths must be used (because of a case of influxdb: client, datastore, devel)

2) 

[  ] - all devel source codes should be up2date so developer can use the latest source codes. Or go get is a better way? Update vs. go get?
[  ] - each tool has its own set (commits) of golang source codes => it is better to used vendored source codes
[  ] - when automating the update, check for changed import paths and if some Provides has been deleted => send a report to email and pause the update => make a manual update

#### TODO ####
[  ] - hybrid vs. vendored vs. deps
[  ] - complete list of [Build]Requires
[  ] - how to automize all builds? Used vendored source codes but at the same time add new package into Fedora