Hi, friends, 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org