Hi, I just got back from vacations. Let me talk with my colleagues and I'll get back to you. thanks again for your work on packaging go On 07/26/2015 11:02 AM, marguerite wrote:

Hi Jordi,

Yesterday I finished replacing go-* packages in openSUSE:Factory to golang-* alternatives, except two packages: go-blackfriday and go-go-md2man, which are from Docker's devel project.

Do you want me to touch those two packages? Docker won't need to change, but those two packages will reside in devel:languages:go from now on with different names.

And it seems your team want to update docker with go packages under old names for 13.2. That is fine actually. New/old packages are compatible.

Marguerite

发自我的 iPhone

在 2015年7月23日，02:46，Jordi Massaguer Pla <jmassaguerpla@suse.de <mailto:jmassaguerpla@suse.de>> 写道：

...

On 07/13/2015 05:14 PM, Marguerite Su wrote:

...

Hi, friends,

Hi Marguerite Su,

I am Jordi from the Docker Team and I am working on the docker packaging, which requires some go packages.

First of all, sorry for not having answered your email. I've been very busy and hadn't look into it. You've done a great job and I am sure you've put a lot time and effort. kudos to you!!!

All this looks very cool and I've noticed you had submit at least 20 packages to devel:languages:go project, using your golang-packaging tool.

For packaging docker we were already using some old go packages which have already been submitted to openSUSE:Factory openSUSE:42 and released for SLE12. I have to look into the details on the implications of using your approach will have on the already released packages and on the submitted ones.

Anyway, I just wanted to let you know you have not been "unnoticed".

...

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 <http://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 <http://google.golang.org/cloud>" and "google.golang.org/cloud/compute/metadata <http://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 togithub.com/golang/glog <http://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