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