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