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> 写道:



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)" 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