Hi Thomas, what about merging the two approaches, I mean, refactoring the golang-packaging to produce a better result and add some macros? Could you send a Pull Request, so that Marguerite can review it :-) ? thanks for taking the time to look into the issue :) regards jordi On 08/11/2015 09:40 AM, Thomas Boerger wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hi Marguerite,

it's really cool that you try to close the gap for current golang packaging, but I'm personally not really happy with this approach.

I think a tool like gem2rpm should be much better as we directly can generate Requires and Provides within the spec file, and we can directly see if it will build or not because of that.

Another thing is that the current approach seem to compile all golang packages, that's useless in so many cases, not any library needs to be compiled, only tools that include a main function outside of tests or examples need to be compiled, the rest just needs to be packaged in an rpm.

If we get to your examples I think a little bit more consistent usage of the archives should be nice as well, some are compressed as bz2, others are compressed as xz. Beside that I'm a fan of the changes generator if we are using service files, like this one I used within my golang packages:

<services> <service name="tar_scm" mode="disabled"> <param name="url">git://github.com/go-xorm/core.git</param> <param name="scm">git</param> <param name="exclude">.git</param> <param name="filename">golang-github-go-xorm-core</param> <param name="versionformat">0.0.0+git.%ct.%h</param> <param name="revision">master</param> <param name="changesgenerate">enable</param> </service> <service name="recompress" mode="disabled"> <param name="file">golang-github-go-xorm-core-*git*.tar</param> <param name="compression">bz2</param> </service> <service name="set_version" mode="disabled"> <param name="basename">golang-github-go-xorm-core</param> </service> <service name="refresh_patches" mode="disabled"> <param name="changesgenerate">enable</param> </service> </services>

And just to show you how I have written some packages manually here is the spec file, it's not perfect and I did not finish that as the macros have not been done entirely:

%define provider github %define provider_tld com %define project go-xorm %define repo core %define repo_name %{repo} %define import_path %{provider}.%{provider_tld}/%{project}/%{repo} %define tar_subdir %{name}-%{version} %define tarball %{tar_subdir}.tar.bz2

Name: golang-%{provider}-%{project}-%{repo} Version: 0.0.0+git.1432046287.7623fc1 Release: 0 Summary: Lightweight & Compitable wrapper of database/sql License: BSD-2-Clause Group: Development/Languages/Other Url: https://%{import_path}

Source0: %{tarball} BuildRequires: go-devel

BuildRoot: %{_tmppath}/%{name}-%{version}-build

%{go_requires} %{go_provides}

%description Core is a lightweight wrapper of sql.DB.

%prep %setup -q -n %{tar_subdir}

%build %goprep %{import_path}

%install %golib %godoc

%files %defattr(-,root,root,-) %doc README.md %{go_dir}/src/*

But again, I really like you afford to get the golang packaging better! These are just my 2 cents. Sorry for the late answer but I have been on vacation.

Regards, Thomas Boerger

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

...

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-or g-x-tools?arch=x86_64&filename=golang-org-x-tools-1.4.2%2Bgit20150710.4c d43f3-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

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVyabtAAoJEFo4j1UoOWC2i9kQAJxlBJ38RhgYLt/zFwo6mZnR lE5jeLjYFfUWtaJXdX1RoySi+TIL+R84/eAD9GxPD5ivDPvjZCNC+egu/S4Fhx8Q nkrDP7FQmxpE+x+Ou1xcYZ6cQdw/6sDmgNTFXWkz+x6UVCaPwJhMojGyeFkJc/1H RahoHY73CCxWbiVDoBlRyyzCXHReAaWoG0CF25HMfK8CWYT6F3o8hQb8P9aaHuSj bSQ4F3m9fFhbw3hfS2g+NnkDKOPCD49gUE9J31+ke0+u/L+HtcBG6y5ffq1HJsvP vIapUoPHGl1CTgzADmqOBJbXumr7VeN7P3F53G2oM9TojjwXM4LKgMkWMtshq1YZ JilpwU6QGasrKvyBm56lcdYTCE4XkFcYnBvNIWn5qO/HYtFrPpNpGwPtpZvvzIAC iTNXWVYhZcjg9U6Y2hFmW/YU4meMsQ+xm7/c6dMsPHv4zT/sqbrt6beWjY0lSNF1 vCJ704E04lqNURpQeJda+z4ScjTtWQJG6JaIujQxAx0K1d/r1iX0+kTMFxtZY/OX OLpBhJu0JWlHSVcrcCEyAGqYRup+4ApdxLAFCHhKQJ+AXItEA9sFbZYQ33IJHePj 9iDELeQiCKSfZPq5xFrJZ27pxhaKiq2nSgcWqgWjiP91TLUiRx8jTSKVBD4rwxaX yisGI1PIxEg+TuNEZCHG =r5rX -----END PGP SIGNATURE-----

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Marguerite On 08/14/2015 04:35 PM, Marguerite Su wrote:

Thanks for this long post, I read it word by word and it insights me much.

eg: https://build.opensuse.org/package/binary/devel:languages:go/golang-gi

You are welcome, I think all of us just want to improve the things as best as possible :). thub-gogo-protobuf?arch=x86_64&filename=golang-github-gogo-protobuf-0.0. 0%2Bgit20150730.8edb24c-1.1.x86_64.rpm&repository=openSUSE_Factory Valid

point, that's not the case for the gem2rpm packaging.

The file.attr method I implemented only solves this problem:

If you build a golang package and it fails because of dependency, in its buildlog, there'll be sentence like "golang.org/x/net not found".

Well then just add BuildRequires: golang(golang.org/x/net).

Stupid, easy. You don't need to bother finding the dependency's package name.

I don't wanted to do something different then just a require for golang(...)

What you were asking for is actually a specfile generator, not a packaging helper.

True

If our question was to automatic packaging golang, gem2rpm stuff will be the thing.

Of course I can implement a program, but:

1. it hides the spec writing process from packagers.

For us, it's a good thing.

For newbie, they don't know how to debug the problem, because a new middle tool introduces more background knowledge to master, eg: gem2rpm introduces many new options and yaml, you wiill be lost when it fails if you don't have a solid background of packaging ruby by hand.

My thought wasn't to hide that from a newbie, I thought about writing all part automatically that we don't need to write it manually.

You mean, leave those uncompiled codes to be intepreted by go at runtime?

What's the difference between your proposal and "packaging source codes"? The later seems to be prohibited in openSUSE? and the efficiency issue?

AFAIK Fedora is doing it like that as well. Just package the sources for libraries and do a compile only for tools that really result in some binary. That way you can avoid devel subpackages for all the .a or similar files.

I used xz archive in my new _service, maybe some old stuff left in my old _service...will fix when I see them next update.

About the changes generator, I couldn't find any documentation...actually this is the first time I hear such thing.

I thought something like that, so this is just a matter of time to get rid of that.

...

And just to show you how I have written some packages manually here is the spec file, it's not perfect and I did not finish that as the macros have not been done entirely:

%define provider github %define provider_tld com %define project go-xorm %define repo core %define repo_name %{repo} %define import_path %{provider}.%{provider_tld}/%{project}/%{repo} %define tar_subdir %{name}-%{version} %define tarball %{tar_subdir}.tar.bz2

Personally I really dislike such over usage of macros...

You implement to much stuff just to get:

1. a package name 2. an importpath 3. a tarball

This is the stuff used by fedora as well, for reference: http://pkgs.fedoraproject.org/cgit/golang-github-codegangsta-cli.git/tre e/golang-github-codegangsta-cli.spec#n28 Kind regards, Thomas Boerger - -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJV0Z4qAAoJEFo4j1UoOWC2J6YQAJKdkIxMFCQtkIJMvVU7Ez+H /pFxVm4cDQSF5kB8BiTms9lqJV3YhTCfqBHpKFRoNpjCSE41xixEUD4Ph1BOqqu9 /yFb0oc95FAwTU0jFV+RhMGmGzlXjpCQYfNEv6iG3hJm7rIQpi6nlNT4xKd+B40N w3cr+5/nkJmbMtxENPgwoPqDole6nnCYjsko7Ywr9VnMOmQ0/dWTh/6d5c7KXulX Ela57BJs48H1Z2iYxjePWspk+1+zH++loVJUbLwO5/XR6FSEEZXbO0IZpl1ZKdEK oZIbEyizZ+9N7H8kN9DJFuCK3jyoOlvtlJrZ3e1KbX6//Cj+r+PCmiHffA7cAtLy x+L/end+VZidd9LDjnbuMrRhzDKNemGZ2GEIwqH3Apw9I5ehdKMMnlzD+rgveISI YQFsNASJGNBrlx5unWdLelYpmETvm+ES5YtAJAVkw+pbzS2N+ltp60p9RLidOIm+ WiV2H3B8YNTf5CPtZosh1d/YPtV21lW1GcYoFJFyuLkPlA7+VqbRfBTUyrbTneyN GiH9UI1QdxSGgIPDtafu0RKnk4TQrwNRVMWZmR1EQ6wTUvVWfIYWl8VvsImn3Rkt aRYhsA61xf+Uhw/Rw4QKrcX6dRtW8FhgTF6LZcSo5hvDWdysY8lVsrkj5CPetq8M iGMv05NynMn6/3LzrGGm =S6z2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org