Last month I saw some posts in this list complaining that our
devel:languages:go is not packager friendly, eg, we don't have
"golang(google.golang.org/cloud/compute/metadata)" style
BuildRequires, and package names are not intuitive (not following
golang's importpath so when an error about importpath occurs, packager
don't know which package provides it)
So I coded.
https://github.com/marguerite/golang-packaging
devel:languages:go/golang-packaging
This is inspired by the logic behind the nodejs-packaging packge in
devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat
package maintainers, using the brand-new system RPM 4.9 provides:
http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator
Basically it has two parts:
* matching rule
* scripts to generate Provides/Requires
When a RPM is being built, if file will install to the dir that
mentioned by the regex matching rule, the self-maintained scripts will
be called and the generated Provides/Requires will be attached along
with the regular Provides/Requires.
So I wrote two scripts:
1. golang.prov will extract importpath from specfile:
"%define importpath xxx" > "%goprep xxx" > URL: xxx
and all the sub-directories in
/home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by
"Source" tag), that is because both "google.golang.org/cloud" and
"google.golang.org/cloud/compute/metadata" are valid importpaths in
golang.
2. golang.req will extract such lines from all *.go files (except for
those .go files inside examples/test directory and *_test.go files,
because examples/tests are useless in production environment, with the
imports inside them):
* import "xxx"
* import {
xxx
"xxx"
}
* import xx "xxx"
these lines can actually be treated as golang's "include" or
build/runtime Requires. and generate such golang() Requires.
So if you're a golang packager, now you can just "BuildRequires:
golang-packaging" and let my scripts to handle Provides/Requires for
you automatically. with this, you can also "BuildRequires:
golang(xxx)" for packages built with golang-packaging.
Additional information:
1. If there're unneeded importpath in examples/tests, just leave them
there, my package will skip them. If such importpath resides in main
.go source codes, "%go_strip_builddep xx" in %prep step can help you
strip them manually.
2. there's one shortcoming, the same as the one for nodejs-packaging:
The build "success" status for a package doesn't mean the package can
be installed without any problem. Because there might be non-fulfilled
Requires for the package, remember to check it again using page like
this:
https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-tools?arch=x86_64&filename=golang-org-x-tools-1.4.2%2Bgit20150710.4cd43f3-1.1.x86_64.rpm&repository=openSUSE_Factory
As to package renames:
I just follow the Fedora style: golang + importpath like string, eg:
golang-github-golang-glog refers to github.com/golang/glog. basically
importpath with ".org/.net/.com" will be okay with my package. You can
refer to the golang-* packages I recently send to devel:languages:go
as examples.
Welcome to help golang package renaming and contribute to my package :-)
Marguerite