Hi, Thomas,
Thanks for this long post, I read it word by word and it insights me much.
On Tue, Aug 11, 2015 at 3:40 PM, Thomas Boerger
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.
You can always see it via web, just on a different page... eg: https://build.opensuse.org/package/binary/devel:languages:go/golang-github-gogo-protobuf?arch=x86_64&filename=golang-github-gogo-protobuf-0.0.0%2Bgit20150730.8edb24c-1.1.x86_64.rpm&repository=openSUSE_Factory 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. What you were asking for is actually a specfile generator, not a packaging helper. 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.
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.
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?
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:
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.
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 Both 1 and 2 are the most important stuff a golang packager wants to know. We should better keep them "plain" so when I opened a specfile, I know its name and importpath at the very first time. It'll be more complicated work even for an auto parser, because the stuff we get from upstream is usually plain. Don't make things too complicated. eg: you implemented two macros to achieve a %{name}-%{version}.tar.bz2, why? Too many substitutions costs brain power for specfile readers. And for search engines. it doesn't know such substitutions. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org