forked from marguerite/golang-packaging
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix for SLE11SP3 #5
Closed
Closed
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
16d4081
add ABI requirement back
marguerite ddf88b7
Merge branch 'master' of https://github.com/openSUSE/golang-packaging
marguerite f595b72
[SLE11SP3]RPM_BUILD_ROOT env is not available at Provides/Requires fi…
marguerite e4666c0
initial shared
marguerite d9c5a8b
Release version 14.10
marguerite File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is still wrong, We don't have any runtime requirement for that, it's always buildtime requirement only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
I do respect you and this is not personal. but actually your style of collaboration...really...I can't fit.
I hate when I replied a lot, you didn't make any correction with strong evidence, and just told me "no it's not". then conversation certainly stopped.
About this commit. it's already been discussed here: https://lists.opensuse.org/opensuse-go/2016-06/msg00000.html. (the last reply came from you too, telling me to talking to someone I don't even know he's actually in the development talk, when I've got support from other objective contributors).
Please remember I'm the author of golang-packaging. If you guys can't make me figure out what you are going to achieve, it'll be really hard to make progress in this project. Because I can switch the Source to https://github.com/marguerite/golang-packaging any time.
Sorry for the inconvenince. But look, you didn't even tell me where I was wrong and I didn't know what you were talking about. How will our collaboration go on?
Marguerite
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe I am stupid. but Linus style of collaboration has one fundamental fact that Linus is one of the major authors of the Kernel. this is not the case. I see little code that convince people. so it sounds to me like an outsider who don't have his hands dirty is pointing here and there without solid evidences and codes.
Or maybe, please, you can treat me as an idiot who hold the nuclear suitcase. You have to stop her from pressing the wrong button. That needs a lot. Not just a "No".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really cool that you are pushing golang packaging forward! Seriously! But as I said, tools built with Golang generally don't have any runtime dependency, it got only build dependencies. That's the big cool thing on Go that you don't depend on any shared stuff. Build a single binary and that's it. But with that change we got the Go compiler as a runtime dependency which is a useless overhead for installing a package that got only a single binary without any dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't want to discourage your work, maybe we should just take the time to chat more interactively via IRC or even Mumble and write some mail with the outcome to the go mailinglist. I think that should be much more productive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @marguerite , nobody ever meant to offend or disregard your work. We are grateful for all the job you and the community did at packaging Go.
I might be wrong, but it looks like this change would cause all the kind of Go packages to require the Go compiler at runtime. This might be fine for static and shared libraries, but it would be useless for Go programs.
Would it be possible to rework this patch to avoid this issue?
As for the big picture about Go packaging, I'm currently writing a response to #4 but I'm being slowed down by other tasks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tboerger
Yes...I also think effective communication is a must...I can get your idea. "we don't need any runtime dependency for any golang binary". what confuse me is...have you extended the definition of "binary" to "any go compiled codes", that is, ".a"...and many other questions which I may have a different/wrong answer from my side...maybe I should send you an email with lists of my questions which can help us find common views....because, you know, we have different options on the same thing, and it is not Politics, the only reason I can think is I may stand on the non-existent soil. And you just didn't explain me, which push me into anxiety.
Marguerite
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flavio
Yes...it will drag requirement of go itself...I know this commit may be not "fine"...but actually I just want to pull the SLE_11_SP3 fix...I just don't know how to send a single commit separately...and, this commit is meaningful to me because in my branch I was implementing "buildmode=shared" and "buildmode=c-shared" and "linkshared" support. In that case, the dependency of go itself is useful...because the shared standard libraries (those .shlibname) are packaged in go itself. But my work just hang there...because there's a bug happened in our go (I'm not sure whether it's packaging or upstream), about which I sent an email to opensuse-go mailing list some days ago.
I promised on the mailing list that I'll require go itself only for shared built stuff. But since my shared build support is not finished. I certianlly don't know how to set these codes conditional.
And please reply to #4 when you're free...because I really didn't find the "strong evidences" that can prevent me from shipping prebuilt ".a" stuff...everyone is telling me "hey! people just use .go!", I know that. But logically it doesn't explain why I shouldn't use ".a". And I found myself a lot of "evidences" that ".a" could be used. we did that because we could do...and I think most of the people didn't think human-being can live on Mars, but that is what NASA is trying to do...:-D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi all. I just hope I can help a bit here... so the problem is that requiring golang(API) = VERSION is needed when packaging .a files , but it is a problem if we are packaging an executable (meaning it has a main function).
So, what we need is basically a way to distinguish the 2 cases.
Right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jordimassaguerpla It's easy to distinguish the 2 cases...executables locate in $GOBIN. it's easy to detect if there's any binary. but I think people from SUSE were talking about some fundamental changes: from shipping
.a
to.go
. I call it fundamental because golang-packaging actually unpacks those.a
to find Provides/Requires.