[opensuse-go] Remove runtime dependency for golang(API)?
From time to time there're failed states in openSUSE:Factory for 3rd-party golang libraries. If A depends on B, when B is updated, A will not get rebuilt, not like
Hi, I've been AFKed for a while so didn't catch up with the fork and recent commits. I'm ok with the fork, it gives me access to openSUSE organization. But actually I'm a little mad with the package updates...someone has brought this kind of behavior on ML once...while I am the author of a project and the only maintainer for a package, suddenly I see my release schedule, versioning scheme and control over my package was totally altered by just leaving a note, from upstream to downstream. YES, I didn't reply in time. But in that hurry? better not. it's not urgent security updates, but some cleaning work (I doubt). I didn't see any respect and open discussion here actually. Newbies for go still have their rights to go, gentlemen. Complaint is over. Bad things just happen everyday. Let's go back to the codes to carry on. While I think I knew golang libraries are statically built when I introduced those runtime requirements. (The commit message makes me feel I didn't write main function in a 10-line C program) It was not to bring go itself in (although there was such side effect) but for ABI consistency. Back when I updated golang from 1.3 to 1.4, I noticed those: OBS will not rebuilt all golang stuff after the main go's version bumps. the standard behavior for C/C++. So I have to update A too to fix the failure which can be resolved by an automatical rebuild. So this is it: if golang updates to 1.7, all 3rd-party golang libraries will still explicitly require golang 1.6 in my design. Then when you build another golang programs depend on one of those libraries. It will get an "unresolvable" error. Very Clear. Instead of processing the build and failing somewhere random because of using go 1.7 and some go libraries built against go 1.6. Unless we can get a solution, either to fix from OBS side or prevent those situations better, we can not just omit the codes I wrote. Marguerite -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Hi Marguerite, it's nice that you have taken the stab to work on it. But we have created the forked project because we don't had any access to your repository and we really needed to remove the runtime dependency for golang. This is simply a no-go to depend on the go compiler for a program that have been built with go. I had not any unresolvable with the updated package helper so far, but I had problems with this dependency. Beside that please create pull requests for changes on the GitHub repository and don't directly accept your submit requests for the packages since we have to work with those tools with multiple people. Best, Thomas Boerger On 06/06/2016 05:11 PM, Marguerite Su wrote:
Hi,
I've been AFKed for a while so didn't catch up with the fork and recent commits.
I'm ok with the fork, it gives me access to openSUSE organization.
But actually I'm a little mad with the package updates...someone has brought this kind of behavior on ML once...while I am the author of a project and the only maintainer for a package, suddenly I see my release schedule, versioning scheme and control over my package was totally altered by just leaving a note, from upstream to downstream.
YES, I didn't reply in time. But in that hurry? better not. it's not urgent security updates, but some cleaning work (I doubt). I didn't see any respect and open discussion here actually. Newbies for go still have their rights to go, gentlemen.
Complaint is over. Bad things just happen everyday. Let's go back to the codes to carry on.
While I think I knew golang libraries are statically built when I introduced those runtime requirements. (The commit message makes me feel I didn't write main function in a 10-line C program)
It was not to bring go itself in (although there was such side effect) but for ABI consistency.
Back when I updated golang from 1.3 to 1.4, I noticed those:
OBS will not rebuilt all golang stuff after the main go's version bumps.
From time to time there're failed states in openSUSE:Factory for 3rd-party golang libraries. If A depends on B, when B is updated, A will not get rebuilt, not like the standard behavior for C/C++. So I have to update A too to fix the failure which can be resolved by an automatical rebuild.
So this is it: if golang updates to 1.7, all 3rd-party golang libraries will still explicitly require golang 1.6 in my design.
Then when you build another golang programs depend on one of those libraries.
It will get an "unresolvable" error. Very Clear. Instead of processing the build and failing somewhere random because of using go 1.7 and some go libraries built against go 1.6.
Unless we can get a solution, either to fix from OBS side or prevent those situations better, we can not just omit the codes I wrote.
Marguerite
-- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Best, Thomas Boerger On 06/06/2016 05:11 PM, Marguerite Su wrote:
Hi,
I've been AFKed for a while so didn't catch up with the fork and recent commits.
I'm ok with the fork, it gives me access to openSUSE organization.
But actually I'm a little mad with the package updates...someone has brought this kind of behavior on ML once...while I am the author of a project and the only maintainer for a package, suddenly I see my release schedule, versioning scheme and control over my package was totally altered by just leaving a note, from upstream to downstream.
YES, I didn't reply in time. But in that hurry? better not. it's not urgent security updates, but some cleaning work (I doubt). I didn't see any respect and open discussion here actually. Newbies for go still have their rights to go, gentlemen.
Complaint is over. Bad things just happen everyday. Let's go back to the codes to carry on.
Hi, I am sorry you feel this way. I appreciate, and I am sure a lot of other people do too, your work and your efforts on maintaining these go packages. Your packages are being used by other people and I think we should all make an effort to manage the conflicts that have and will arise. github and open build service gives us tools to create small changes and discuss on them: Pull Requests and Submit Request. What about we all use these tools from now on to prevent future situations like this? What about we follow this rule: "If one wants to add new things, creates a Pull Request in github/openSUSE/golang-packaging" "Then, someone else who is maintainer of the package, has to review and accept this request." We could use http://lgtm.co which will enforce it. If we do that in github, then I think we could use a _service file in obs that can get the code automatically, without further revision. Will that work for you? Will that work for everybody else?
While I think I knew golang libraries are statically built when I introduced those runtime requirements. (The commit message makes me feel I didn't write main function in a 10-line C program)
It was not to bring go itself in (although there was such side effect) but for ABI consistency.
Back when I updated golang from 1.3 to 1.4, I noticed those:
OBS will not rebuilt all golang stuff after the main go's version bumps.
From time to time there're failed states in openSUSE:Factory for 3rd-party golang libraries. If A depends on B, when B is updated, A will not get rebuilt, not like the standard behavior for C/C++. So I have to update A too to fix the failure which can be resolved by an automatical rebuild.
So this is it: if golang updates to 1.7, all 3rd-party golang libraries will still explicitly require golang 1.6 in my design.
Then when you build another golang programs depend on one of those libraries.
It will get an "unresolvable" error. Very Clear. Instead of processing the build and failing somewhere random because of using go 1.7 and some go libraries built against go 1.6.
Unless we can get a solution, either to fix from OBS side or prevent those situations better, we can not just omit the codes I wrote.
I think we should find another way to fix this. What about using "BuildRequires: go". Wouldn't that retrigger a build? jordi
Marguerite
-- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
"If one wants to add new things, creates a Pull Request in github/openSUSE/golang-packaging" "Then, someone else who is maintainer of the package, has to review and accept this request."
We could use http://lgtm.co which will enforce it.
Which is proprietary. Is there not a free software version of that? :/ -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 06/10/2016 10:10 AM, Aleksa Sarai wrote:
"If one wants to add new things, creates a Pull Request in github/openSUSE/golang-packaging" "Then, someone else who is maintainer of the package, has to review and accept this request."
We could use http://lgtm.co which will enforce it.
Which is proprietary. Is there not a free software version of that? :/
It's not, it's opensource if you want to host your own version!
https://github.com/lgtmco/lgtm
--
Thomas Boerger
On 2016-06-14 18:46, Thomas Boerger wrote:
On 06/10/2016 10:10 AM, Aleksa Sarai wrote:
"If one wants to add new things, creates a Pull Request in github/openSUSE/golang-packaging" "Then, someone else who is maintainer of the package, has to review and accept this request."
We could use http://lgtm.co which will enforce it.
Which is proprietary. Is there not a free software version of that? :/
It's not, it's opensource if you want to host your own version! https://github.com/lgtmco/lgtm
Odd. I couldn't find it linked on the website you provided. :P I might consider getting the OCI to use this instead of pullapprove. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 06/15/2016 05:55 AM, Aleksa Sarai wrote:
Odd. I couldn't find it linked on the website you provided. :P
I might consider getting the OCI to use this instead of pullapprove.
Yeah it had been closed source at the beginning and then the author (the
same as for drone) has opensourced it. Maybe it's lacking some links :).
--
Thomas Boerger
YES, I didn't reply in time. But in that hurry? better not. it's not urgent security updates, but some cleaning work (I doubt).
I appreciate the work you did for packaging Go programs, and AFAIK you're still the maintainer for that project. The reason for the fork was because *every Go package in OBS was broken*. The issue was that the golang(API) generation script accidentally generated the wrong version (I think it generated 1.6 when it should've been 1.6.1, or something like that). Since we didn't have go=1.6 packaged (but we did have go=1.6.1), things broke badly.
I didn't see any respect and open discussion here actually. Newbies for go still have their rights to go, gentlemen.
We didn't mean to disrespect you, we just wanted to fix the fact that the entire build system for Go-based packages was temporarily broken (and this was all happening near the release of a few Go-based packages for openSUSE). IIRC @flavio made you a maintainer of the new project anyway -- if not, I'm sure they would be happy to make you one.
It will get an "unresolvable" error. Very Clear. Instead of processing the build and failing somewhere random because of using go 1.7 and some go libraries built against go 1.6.
Can you explain what you mean by "go libraries"? Since everything is statically compiled or vendored by the project itself (in most cases), what libraries are you referring to? AFAIK proper shared library support is still an RFC for the Go project (I can't find the link at the moment, but I remember reading an RFC for it a while ago).
Unless we can get a solution, either to fix from OBS side or prevent those situations better, we can not just omit the codes I wrote.
I actually am not against the original code written (and thought that the ABI locking was a good idea), we just had to hotfix it because we couldn't build or release any Go-based packages for a few days. A better fix would be to figure out why the golang(API) macro generation produced the wrong version value, and fix _that_. Or maybe just check that the major-minor versions are the same for the compiler? The version checks are too strict given that it seems that Go doesn't bump their API version with each patchlevel release. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Hi, I didn't reply because I need some time to set up the demostration about why keeping ABI consistent is important. Aleksa was right. The code before had some problems matching 1.6.1. I fixed that in my fork. Maybe the original pull request was done when go was 1.5 so this exception was not considered. "go libraries" I mean 3rd party go modules/projects like %{go_archdir}/github.com/shurcooL/sanitized_anchor_name.a I didn't read too many golang books, so if my saying is wrong, correct me please. For C I think static library is also library. We have a common knowledge here that go stuff is statically compiled. But how static? I have little knowledge in programming, I don't know if the compiled stuff can be run without the presence of golang itself. If someone knows, please teach me. But there's still one thing we need to consider, BuildRequires. If A buildrequires B, no matter whether B is compiled statically or not, it'll be involved. But what if we are building A with go 1.6.1, while B is compiled before with a different version (ABI) of go? Here's my result: https://build.opensuse.org/package/live_build_log/home:MargueriteSu:go_test1... "import /usr/lib64/go/contrib/pkg/linux_amd64/github.com/shurcooL/sanitized_anchor_name.a: object is [linux amd64 go1.4.3 X:precisestack] expected [linux amd64 go1.6.1 X:none]" I set up a project with go 1.4.3 and modified golang-packaging/golang-github-shurcool-sanitized_anchor_name to make sure the sanitized_anchor_name is built with go 1.4.3. Then I set up another project with go 1.6.1 and golang-github-russross-blackfriday, while aggregating the compiled sanitized_anchor_name. This happens everywhere on OBS, even in a same project due to racing problems or something I don't know. I can tell with my experience of maintaining go, this must be considered. Not to say, there're lots of home projects that are not updated that quickly as Factory and devel:languages:go. Sometimes the worker for home projects just stopped working. sometimes the user has his own piece of go. That is what I want to show you guys: the things compiled with different versions of go can't be used to build further things with this version of go. So the ABI consistence is a must. What do you think? And Jordi just mentioned why not BuildRequires? Actually BuildRequires of go is there from day one. But it just did not help in the old days. And I would like to know why you guys didn't want "Requires: golang(API) = 1.6" there? Because compiled stuff doesn't need to runtime require golang itself? That is, Can I uninstall go package without breaking my existing go compiled binaries? Marguerite -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Hi, generally we can even update the golang-packaging helpers to just not compile any pure library unless it got a main function defined. That's what darix initially suggested because the pure libs never needs to be compiled standalone, we just need the source files for the build time of tools including a main function. Tools built with Go got in most cases not any runtime dependency, so we should only have build requirements. Best, Thomas Boerger On 06/12/2016 03:57 PM, Marguerite Su wrote:
Hi,
I didn't reply because I need some time to set up the demostration about why keeping ABI consistent is important.
Aleksa was right. The code before had some problems matching 1.6.1. I fixed that in my fork. Maybe the original pull request was done when go was 1.5 so this exception was not considered.
"go libraries" I mean 3rd party go modules/projects like %{go_archdir}/github.com/shurcooL/sanitized_anchor_name.a I didn't read too many golang books, so if my saying is wrong, correct me please. For C I think static library is also library.
We have a common knowledge here that go stuff is statically compiled. But how static? I have little knowledge in programming, I don't know if the compiled stuff can be run without the presence of golang itself. If someone knows, please teach me.
But there's still one thing we need to consider, BuildRequires.
If A buildrequires B, no matter whether B is compiled statically or not, it'll be involved.
But what if we are building A with go 1.6.1, while B is compiled before with a different version (ABI) of go?
Here's my result:
https://build.opensuse.org/package/live_build_log/home:MargueriteSu:go_test1...
"import /usr/lib64/go/contrib/pkg/linux_amd64/github.com/shurcooL/sanitized_anchor_name.a: object is [linux amd64 go1.4.3 X:precisestack] expected [linux amd64 go1.6.1 X:none]"
I set up a project with go 1.4.3 and modified golang-packaging/golang-github-shurcool-sanitized_anchor_name to make sure the sanitized_anchor_name is built with go 1.4.3.
Then I set up another project with go 1.6.1 and golang-github-russross-blackfriday, while aggregating the compiled sanitized_anchor_name.
This happens everywhere on OBS, even in a same project due to racing problems or something I don't know.
I can tell with my experience of maintaining go, this must be considered.
Not to say, there're lots of home projects that are not updated that quickly as Factory and devel:languages:go. Sometimes the worker for home projects just stopped working. sometimes the user has his own piece of go.
That is what I want to show you guys:
the things compiled with different versions of go can't be used to build further things with this version of go.
So the ABI consistence is a must. What do you think?
And Jordi just mentioned why not BuildRequires? Actually BuildRequires of go is there from day one. But it just did not help in the old days.
And I would like to know why you guys didn't want "Requires: golang(API) = 1.6" there? Because compiled stuff doesn't need to runtime require golang itself? That is, Can I uninstall go package without breaking my existing go compiled binaries?
Marguerite
--
Thomas Boerger
On Tue, Jun 14, 2016 at 4:52 PM, Thomas Boerger
Hi,
generally we can even update the golang-packaging helpers to just not compile any pure library unless it got a main function defined. That's what darix initially suggested because the pure libs never needs to be compiled standalone, we just need the source files for the build time of tools including a main function.
Tools built with Go got in most cases not any runtime dependency, so we should only have build requirements.
Most of the go packages we build and ship are libraries. we didn't ship many golang applications. eg: sanitized_anchor_name and blackfriday. I didn't find a main function in them. And in my design, the golang-github/googlecode/gopkg-* stuff are all libraries. golang applications are using a different naming scheme, eg: snapd (just the upstream name as other applications). So in your theory, they shouldn't exist in openSUSE or they should exist in source code format (.go). Basically you cut off the whole devel:languages:go In my opinion, we ship not only prebuilt golang applications ("tools") but also the common 3rd libraries used for golang development. not in source format but in binary format. That is, the devel:languages:go repository is designed to be that way. You have to allow redundant stuff. Secondly, I'm implementing the shared library support for golang and its 3rd libraries. the runtime requirement is needed anyway. That is, my development for this toolkit is not finished. Unless you guys can help with some real progress with me. I will continue the development with my mind centered. all other stuff will be considered as feature requests Marguerite -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
"go libraries" I mean 3rd party go modules/projects like %{go_archdir}/github.com/shurcooL/sanitized_anchor_name.a I didn't read too many golang books, so if my saying is wrong, correct me please. For C I think static library is also library.
Okay, so the issue is that as far as I'm aware the Go compiler doesn't currently (officially) support using static libraries in this way. The way that we currently package static libraries is quite a bit of a hack, if you read the RFC for adding the ability to have proper static libraries with Go[1].
That is what I want to show you guys:
the things compiled with different versions of go can't be used to build further things with this version of go.
So the ABI consistence is a must. What do you think?
I'm not sure I actually understand what packages actually go through in OBS when building a Go program. I'll have to look -- because it looks like you're doing some hacks to get Go to use precompiled .a files. Currently this is not fully supported AFAIK and I remember seeing an RFC about making this an official thing.
And I would like to know why you guys didn't want "Requires: golang(API) = 1.6" there? Because compiled stuff doesn't need to runtime require golang itself? That is, Can I uninstall go package without breaking my existing go compiled binaries?
This is a slightly complicated question to answer. Traditionally, Go was completely statically compiled, so you don't need anything other than the binary itself. Unfortunately, this made things complicated and caused bugs with libc when you wanted to use DNS resolution functions. So if your binary doesn't use any network-related functions (and none of it's dependencies do), it will be entirely statically compiled. However, if your binary is not _entirely_ statically compiled all of the Go code *will* be statically compiled no matter what. The only question is whether or not some C libraries will be statically compiled into your code or not (this gets even more complicated with cgo). But all of this is handled by OBS already (it does and `ldd` of the binary to figure out what libraries the binary is using and then adds implict Requires to the final package). -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 2016-06-17 14:05, Aleksa Sarai wrote:
hack, if you read the RFC for adding the ability to have proper static libraries with Go[1].
you forgot the link. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
hack, if you read the RFC for adding the ability to have proper static libraries with Go[1].
you forgot the link.
I actually couldn't find the link and forgot to remove the reference. I *do* remember seeing the RFC on hacker news. I'll see if I can find it. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
hack, if you read the RFC for adding the ability to have proper static libraries with Go[1].
you forgot the link.
I actually couldn't find the link and forgot to remove the reference. I *do* remember seeing the RFC on hacker news. I'll see if I can find it.
Here's the proposal[1]. [1]: https://github.com/golang/proposal/blob/master/design/2775-binary-only-packa... -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On Sat, 18 Jun 2016 00:29:12 +1000
Aleksa Sarai
hack, if you read the RFC for adding the ability to have proper static libraries with Go[1].
you forgot the link.
I actually couldn't find the link and forgot to remove the reference. I *do* remember seeing the RFC on hacker news. I'll see if I can find it.
Here's the proposal[1].
[1]: https://github.com/golang/proposal/blob/master/design/2775-binary-only-packa...
now imagine they would do the proper thing and support shared library versions. O M G darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
hack, if you read the RFC for adding the ability to have proper static libraries with Go[1].
you forgot the link.
I actually couldn't find the link and forgot to remove the reference. I *do* remember seeing the RFC on hacker news. I'll see if I can find it.
Here's the proposal[1].
[1]: https://github.com/golang/proposal/blob/master/design/2775-binary-only-packa...
now imagine they would do the proper thing and support shared library versions. O M G
It annoys me *so much* that Docker's plugin system uses JSON-over-sockets because Go didn't support dlopen(3) constructions. They picked a model that doesn't make much sense IMO because the language was missing a feature (which is the story of Docker and Go, to be honest). -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Hi, I took me some time to do some tests and try to understand the issues. I am going to make a small summary here. We have 2 options: 1- add back the*"Requires: **golang(API) = **X.Y.Z" *2- Do not build the .a files, but just***provide the source code** * My proposal:* *Requires: golang(API) = X.Y.Z, and provide the source code in a subpackage called "-devel"* _Long explanation_ * *Context *In devel:languages:go, we are packaging golang-* packages so that they contain binary *.a files . If we want to use this *.a files, we need to add the packages as "BuildRequires". This happens for example for docker. Docker -- "Build Requires" --> md2man md2man -- "Build Requires" --> blackfriday md2man and blackfriday are both golang-* packages. The problem is that all of them need to be built with the same go version. Otherwise, when packaging go, you get this error: /error:object is [linux amd64 go1.6.2 X:none] expected [linux amd64 go1.6.1 X:none]"/ *Options* Thus we have basically 2 options: 1- add back the*"Requires: **golang(API) = **X.Y.Z",* as Marguerite already suggested (see her commit in her namespace https://github.com/marguerite/golang-packaging/commit/16d4081420ba606c5f476a...) Here there was some confusion. This package is a "*build**dependency*", see docker as an example, thus, in this scenario, you should see the "Requires" as "BuildRequires". I don't think we are expecting anyone installing it unless they want to build a go program. 2- Do not build the .a files, but just *provide the source code*, so that the final package builds everything. This is what Darix and Aleksa suggested, and it is what Fedora guys are doing. See the example of how to package a library at the end of its wiki page: https://fedoraproject.org/wiki/PackagingDrafts/Go Note, they are providing the files in a subpackage called "-devel". * Comparison of options* The advantage of this second approach is that you can have different go versions but only one golang-A package, while with the first approach, you should have as much golang-A packages as go versions, for example: First approach: go1-5 go1-6 golang-A-1.5 golang-A-1.6 Second approach: go1.5 go1.6 golang-A However, the first approach would have sense if we were using *shared libraries*. Marguerite has stated that she is working on that direction. * My proposal* Since Marguerite has already done the job as for providing the binaries, and she is doing so because she has plans for shipping it as shared libraries, I would not drop all her job and _add back the__*"Requires: *__*golang(API) = **X.Y.Z". *_However, I would also add a *_subpackage called "-devel" which provides the source files_* so that we can use that as Fedora guys do, cause in my opinion, that is a better approach.
Since Marguerite has already done the job as for providing the binaries, and she is doing so because she has plans for shipping it as shared libraries, I would not drop all her job and _add back the__*"Requires: *__*golang(API) = **X.Y.Z".
What do you mean by "shared libraries"? Go doesn't have support for .so's if that's what you mean. If we're just sharing the .a files, then that's ... fine -- except for all of the caveats mentioned in the RFC I referenced before in the thread. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Hi, Jordi, I am glad you know what I said completely. Just one thing...the suggestion you made...exists. The Fedora way was introduced by early openSUSE go maintainers, I just renamed it to "-source" to better reflect what this sub-package really is. And I myself usually don't add that macro to my specfile. Because I don't like souce codes shipped to the end users. (traditionally, they recommends/requires the -source sub-package for the main package, so a user may have accidentally installed many source codes.) I must admit that I didn't realize the real purpose of -source sub-packages. I think I need further investigation on it to see if the binary (.a) of a package build with source codes of its dependencies contains "import" declarations. Because currently golang-packaging just unpack the result .a files and check "import" to determine runtime dependencies. And I don't what to argue about whether golang has real shared libraries. All I know is that I enabled building of *.sharedlibname stuff in our main go package. And I can build .so files that depends on them. So I think to add "Requires: golang(API)" to shared builds is a must. I know it may sounds tricky. But technically, I can check buildflags and place a plain text file in /tmp (the easiest way, just like the way I check importpath) to tell the golang.req/prov whether the build is shared or not. Then decide whether to add that Requirement. Just need some spare time. Nowadays I'm busy in fixing bugs that prevent packages built with gcc6. Marguerite -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 06/21/2016 05:47 PM, Marguerite Su wrote:
Hi, Jordi,
I am glad you know what I said completely.
Just one thing...the suggestion you made...exists.
The Fedora way was introduced by early openSUSE go maintainers, I just renamed it to "-source" to better reflect what this sub-package really is. And I myself usually don't add that macro to my specfile. Because I don't like souce codes shipped to the end users. (traditionally, they recommends/requires the -source sub-package for the main package, so a user may have accidentally installed many source codes.)
I must admit that I didn't realize the real purpose of -source sub-packages.
I see! That is cool. I wasn't aware of that https://github.com/marguerite/golang-packaging/blob/master/macros.go#L96 https://github.com/marguerite/golang-packaging/blob/master/macros.go#L100 So I guess one only needs to add %gosrc_package(NAME:REQUIRES) and in the install section %gosrc is that it?
(...)
So I think to add "Requires: golang(API)" to shared builds is a must.
+1
On Wed, Jun 22, 2016 at 12:02 AM, Jordi Massaguer Pla
I see! That is cool. I wasn't aware of that
https://github.com/marguerite/golang-packaging/blob/master/macros.go#L96 https://github.com/marguerite/golang-packaging/blob/master/macros.go#L100
So I guess one only needs to add
%gosrc_package(NAME:REQUIRES)
and in the install section
%gosrc
is that it?
Yes, although I think I need to decoupe the %{name} and %{name}-source packages. Unlike C stuff, if %{name}-source is installed, there's no need to install %{name} again. And for end users, installation of %{name} will not drag %{name}-source... One shortcoming for the current %gosrc is: It can't determine the data files. Usually there's no data files at all. But if there is (I met once when packaging lime text editor), I think nobody can do anything with scripts. Situations are different. So it may requires packagers to investigate in such cases. Marguerite -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
You should really talk to darix. We already discussed that in the past and we said that we should only provide the source files for libraries and we don't need to build any *.a file. On 06/21/2016 05:19 PM, Jordi Massaguer Pla wrote:
Hi,
I took me some time to do some tests and try to understand the issues. I am going to make a small summary here.
We have 2 options:
1- add back the*"Requires: **golang(API) = **X.Y.Z" *2- Do not build the .a files, but just***provide the source code**
* My proposal:*
*Requires: golang(API) = X.Y.Z, and provide the source code in a subpackage called "-devel"*
_Long explanation_
* *Context
*In devel:languages:go, we are packaging golang-* packages so that they contain binary *.a files .
If we want to use this *.a files, we need to add the packages as "BuildRequires". This happens for example for docker.
Docker -- "Build Requires" --> md2man md2man -- "Build Requires" --> blackfriday
md2man and blackfriday are both golang-* packages.
The problem is that all of them need to be built with the same go version. Otherwise, when packaging go, you get this error:
/error:object is [linux amd64 go1.6.2 X:none] expected [linux amd64 go1.6.1 X:none]"/
*Options*
Thus we have basically 2 options:
1- add back the*"Requires: **golang(API) = **X.Y.Z",* as Marguerite already suggested (see her commit in her namespace https://github.com/marguerite/golang-packaging/commit/16d4081420ba606c5f476a...)
Here there was some confusion. This package is a "*build**dependency*", see docker as an example, thus, in this scenario, you should see the "Requires" as "BuildRequires". I don't think we are expecting anyone installing it unless they want to build a go program.
2- Do not build the .a files, but just *provide the source code*, so that the final package builds everything.
This is what Darix and Aleksa suggested, and it is what Fedora guys are doing. See the example of how to package a library at the end of its wiki page:
https://fedoraproject.org/wiki/PackagingDrafts/Go
Note, they are providing the files in a subpackage called "-devel". *
Comparison of options*
The advantage of this second approach is that you can have different go versions but only one golang-A package, while with the first approach, you should have as much golang-A packages as go versions, for example:
First approach:
go1-5 go1-6 golang-A-1.5 golang-A-1.6
Second approach:
go1.5 go1.6 golang-A
However, the first approach would have sense if we were using *shared libraries*. Marguerite has stated that she is working on that direction.
* My proposal*
Since Marguerite has already done the job as for providing the binaries, and she is doing so because she has plans for shipping it as shared libraries, I would not drop all her job and _add back the__*"Requires: *__*golang(API) = **X.Y.Z".
*_However, I would also add a *_subpackage called "-devel" which provides the source files_* so that we can use that as Fedora guys do, cause in my opinion, that is a better approach.
-- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
participants (6)
-
Aleksa Sarai -
Jordi Massaguer Pla -
Marcus Rueckert -
Marcus Rückert
-
Marguerite Su -
Thomas Boerger