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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the use of gccgo on architectures without golang-go #36

Merged
merged 1 commit into from Jun 15, 2016

Conversation

Projects
None yet
5 participants
@anthonyfok
Contributor

anthonyfok commented Jan 14, 2016

  • Build-Depends on gccgo where golang-go is not available
    i.e., [!amd64 !arm64 !armel !armhf !i386 !ppc64 !ppc64el]
  • Remove Depends on golang-go

When the debian/control file of a Go program and its dependencies have this change made, this allows the Go program to be built on more platforms, especially powerpc, sparc64, s390x, mips and mipsel, and hopefully more.

For example, see https://buildd.debian.org/status/package.php?p=go-md2man for the current build status of go-md2man. Of course, my own personal goal is to have Hugo available on as many platforms as possible. 馃槈

Many thanks!

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Jan 14, 2016

Contributor

It鈥檚 a bit unfortunate that we鈥檇 have to maintain the list of architectures if we merged this pull request. Especially since it might change in the future, and then we鈥檇 need to update all our packages. I鈥檓 not saying this isn鈥檛 doable, but I鈥檓 not aware of any communication with regards to mass-changes in our packages.

Is there a way with which we can use golang-go or gccgo automatically, depending on availability? E.g. Depends: golang-go | gccgo?

Contributor

stapelberg commented Jan 14, 2016

It鈥檚 a bit unfortunate that we鈥檇 have to maintain the list of architectures if we merged this pull request. Especially since it might change in the future, and then we鈥檇 need to update all our packages. I鈥檓 not saying this isn鈥檛 doable, but I鈥檓 not aware of any communication with regards to mass-changes in our packages.

Is there a way with which we can use golang-go or gccgo automatically, depending on availability? E.g. Depends: golang-go | gccgo?

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 14, 2016

Contributor

It is actually two problems, one with Build-Depends, and another with Depends. I will talk about them separately.

  1. It is indeed a bit unfortunate, but it seems to be the only way it would work with sbuild (buildd.debian.org) because, as we are now all aware, sbuild ignores alternatives in Build-Depends, so Build-Depends: golang-go | gccgo does not work.

    So, unless we can convince "the powers that be" to change sbuild, the only thing we can do is to change our own packages.

    Or, another way, perhaps, would be to create some kind of a architecture-specific default-golang (just a random name that popped into my head) that depends on golang-go or gccgo depending on which architecture it is? That way, it is only one package to maintain.

  2. Depends: golang-go, on the other hand, affects not the package itself, in a sense that it can be built, even by sbuild on architectures without golang-go, but it cannot be installed on such architectures, such that the package itself cannot be used by other packages that depend on it, rendering it unusable.

    You will notice that, in my patch, I have simply chosen to remove Depends: golang-go altogether, as I have noticed that many older Go packages that were not created with dh-make-golang (such as the ones that @tianon handcrafted) simply did not have Depends: golang-go, and they have worked just fine.

    Of course, if you think it is better not to leave it out, we can always use Depends: golang-go | gccgo.

As you can see, the troublesome part is with Build-Depends, not Depends. :-)

I鈥檓 not saying this isn鈥檛 doable, but I鈥檓 not aware of any communication with regards to mass-changes in our packages.

Hehe, I was just testing the water with go-md2man because it only depends on two other Go library -dev packages. But you are right, if we were to follow through, it would eventually result in a mass-change of all related Go packages. Are you suggesting that we bring this back to pkg-go-maintainers@l.a.d.o for further discussions with everyone? :-)

Contributor

anthonyfok commented Jan 14, 2016

It is actually two problems, one with Build-Depends, and another with Depends. I will talk about them separately.

  1. It is indeed a bit unfortunate, but it seems to be the only way it would work with sbuild (buildd.debian.org) because, as we are now all aware, sbuild ignores alternatives in Build-Depends, so Build-Depends: golang-go | gccgo does not work.

    So, unless we can convince "the powers that be" to change sbuild, the only thing we can do is to change our own packages.

    Or, another way, perhaps, would be to create some kind of a architecture-specific default-golang (just a random name that popped into my head) that depends on golang-go or gccgo depending on which architecture it is? That way, it is only one package to maintain.

  2. Depends: golang-go, on the other hand, affects not the package itself, in a sense that it can be built, even by sbuild on architectures without golang-go, but it cannot be installed on such architectures, such that the package itself cannot be used by other packages that depend on it, rendering it unusable.

    You will notice that, in my patch, I have simply chosen to remove Depends: golang-go altogether, as I have noticed that many older Go packages that were not created with dh-make-golang (such as the ones that @tianon handcrafted) simply did not have Depends: golang-go, and they have worked just fine.

    Of course, if you think it is better not to leave it out, we can always use Depends: golang-go | gccgo.

As you can see, the troublesome part is with Build-Depends, not Depends. :-)

I鈥檓 not saying this isn鈥檛 doable, but I鈥檓 not aware of any communication with regards to mass-changes in our packages.

Hehe, I was just testing the water with go-md2man because it only depends on two other Go library -dev packages. But you are right, if we were to follow through, it would eventually result in a mass-change of all related Go packages. Are you suggesting that we bring this back to pkg-go-maintainers@l.a.d.o for further discussions with everyone? :-)

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 14, 2016

Contributor

Oh, I forgot to mention, perhaps the change to architecture-specific Build-Depends is unnecessary for "Architecture: all" packages because all of us in the pkg-go team are using platforms where golang-go _is_ available. And since they are "Architecture: all" and cover all architectures already, buildd (sbuild) won't try to rebuild them.

So, to limit the impact, we could limit the use of architecture-specific Build-Depends, i.e.

Build-Depends: ...
               golang-go [amd64 arm64 armel armhf i386 ppc64 ppc64el],
               gccgo [!amd64 !arm64 !armel !armhf !i386 !ppc64 !ppc64el],
               ...

to Go programs only.

Contributor

anthonyfok commented Jan 14, 2016

Oh, I forgot to mention, perhaps the change to architecture-specific Build-Depends is unnecessary for "Architecture: all" packages because all of us in the pkg-go team are using platforms where golang-go _is_ available. And since they are "Architecture: all" and cover all architectures already, buildd (sbuild) won't try to rebuild them.

So, to limit the impact, we could limit the use of architecture-specific Build-Depends, i.e.

Build-Depends: ...
               golang-go [amd64 arm64 armel armhf i386 ppc64 ppc64el],
               gccgo [!amd64 !arm64 !armel !armhf !i386 !ppc64 !ppc64el],
               ...

to Go programs only.

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 15, 2016

Contributor

I have updated the patch to add architecture-specific list to -type program only:

  • For programs, Build-Depends on gccgo where golang-go is not available
    i.e., [!amd64 !arm64 !armel !armhf !i386 !ppc64 !ppc64el]
  • For libraries, Depends on "golang-go | gccgo" instead of just "golang-go"
Contributor

anthonyfok commented Jan 15, 2016

I have updated the patch to add architecture-specific list to -type program only:

  • For programs, Build-Depends on gccgo where golang-go is not available
    i.e., [!amd64 !arm64 !armel !armhf !i386 !ppc64 !ppc64el]
  • For libraries, Depends on "golang-go | gccgo" instead of just "golang-go"
@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jan 15, 2016

Contributor

For libraries, we only install the source code, so I don't see why golang-go would be any more than Suggests (if listed at all) -- that's why I've removed it from a bunch of my own pkg-go creations. Any particular reason we ought to Depends on golang-go for packages that only include source?

Contributor

tianon commented Jan 15, 2016

For libraries, we only install the source code, so I don't see why golang-go would be any more than Suggests (if listed at all) -- that's why I've removed it from a bunch of my own pkg-go creations. Any particular reason we ought to Depends on golang-go for packages that only include source?

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 15, 2016

Contributor

+1 on what @tianon said. 馃憤

Contributor

anthonyfok commented Jan 15, 2016

+1 on what @tianon said. 馃憤

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Jan 18, 2016

Contributor

Thanks for the thoughtful replies.

So, unless we can convince "the powers that be" to change sbuild, the only thing we can do is to change our own packages.

Is there a bug report already that we can refer to in a comment? If not, could you file one please? I certainly would be happy if the sbuild issue could be fixed, as we鈥檝e run into that in the past already (with package renames).

Or, another way, perhaps, would be to create some kind of a architecture-specific default-golang (just a random name that popped into my head) that depends on golang-go or gccgo depending on which architecture it is? That way, it is only one package to maintain.

That sounds reasonable to me, at least as a workaround for the time being. I think a slightly better naming choice might be golang-any, similar to libjson-any-perl or python-anyjson, but I don鈥檛 have strong feelings about the name.

@tianon @paultag Do you agree to have golang-any in src:golang?

For libraries, we only install the source code, so I don't see why golang-go would be any more than Suggests (if listed at all)

Actually, I think we can indeed remove the Depends entirely. I was pondering whether having it would be an advantage for people who want to develop against a given library and are not familiar with the ecosystem. However, since the Go libraries in Debian are explicitly not for end-user development, but only for packaging Go programs, this isn鈥檛 a valid use-case. So, yes, let鈥檚 remove it.

Contributor

stapelberg commented Jan 18, 2016

Thanks for the thoughtful replies.

So, unless we can convince "the powers that be" to change sbuild, the only thing we can do is to change our own packages.

Is there a bug report already that we can refer to in a comment? If not, could you file one please? I certainly would be happy if the sbuild issue could be fixed, as we鈥檝e run into that in the past already (with package renames).

Or, another way, perhaps, would be to create some kind of a architecture-specific default-golang (just a random name that popped into my head) that depends on golang-go or gccgo depending on which architecture it is? That way, it is only one package to maintain.

That sounds reasonable to me, at least as a workaround for the time being. I think a slightly better naming choice might be golang-any, similar to libjson-any-perl or python-anyjson, but I don鈥檛 have strong feelings about the name.

@tianon @paultag Do you agree to have golang-any in src:golang?

For libraries, we only install the source code, so I don't see why golang-go would be any more than Suggests (if listed at all)

Actually, I think we can indeed remove the Depends entirely. I was pondering whether having it would be an advantage for people who want to develop against a given library and are not familiar with the ecosystem. However, since the Go libraries in Debian are explicitly not for end-user development, but only for packaging Go programs, this isn鈥檛 a valid use-case. So, yes, let鈥檚 remove it.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jan 18, 2016

Contributor

I definitely like the golang-any solution better than what was proposed in 780355. 馃憤 (Although really interested in @paultag's thoughts on the subject too.)

Contributor

tianon commented Jan 18, 2016

I definitely like the golang-any solution better than what was proposed in 780355. 馃憤 (Although really interested in @paultag's thoughts on the subject too.)

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 29, 2016

Contributor

I have just force-pushed a commit removing the Depends on golang-go entirely. :-)

Contributor

anthonyfok commented Jan 29, 2016

I have just force-pushed a commit removing the Depends on golang-go entirely. :-)

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Jan 31, 2016

Contributor

@paultag Do you have any objections against a golang-any package?

Contributor

stapelberg commented Jan 31, 2016

@paultag Do you have any objections against a golang-any package?

@paultag

This comment has been minimized.

Show comment
Hide comment
@paultag

paultag Jan 31, 2016

Member

Yeah, maintaining a list of arches on every source package seems like it won't scale super well. I don't really want to get into bike shedding a name, so golang-any sounds great.

As for the concept of golang-any, it's interesting. It matches with my worldview and will give us a single place to pick a golang compiler. This might come in handy once (or rather, if) we need to have two versions of go in the archive at the same time.

I'm with @tianon, sounds better than other ideas so far, anyway.

I say let's go for it.

Member

paultag commented Jan 31, 2016

Yeah, maintaining a list of arches on every source package seems like it won't scale super well. I don't really want to get into bike shedding a name, so golang-any sounds great.

As for the concept of golang-any, it's interesting. It matches with my worldview and will give us a single place to pick a golang compiler. This might come in handy once (or rather, if) we need to have two versions of go in the archive at the same time.

I'm with @tianon, sounds better than other ideas so far, anyway.

I say let's go for it.

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Feb 1, 2016

Contributor

Great, it looks like we all agree.

@anthonyfok Could you prepare a patch to add the golang-any package to the golang source package please?

Contributor

stapelberg commented Feb 1, 2016

Great, it looks like we all agree.

@anthonyfok Could you prepare a patch to add the golang-any package to the golang source package please?

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Apr 27, 2016

Contributor

@anthonyfok Could you prepare a patch to add the golang-any package to the golang source package please?

Sorry for the three-month delay. I finally filed a bug report with patch on the Debian BTS, see https://bugs.debian.org/822746.

However, it turns out that there has been new development: @mwhudson has created src:golang-defaults (similar to srd:gcc-defaults) which provides golang-any and allows the co-installation of multiple versions of Go. Please see his reply at https://bugs.debian.org/822746 as well as the following proposed changes in the Git repositories on Alioth:

I think @mwhudson's work is a more well-thought-out, future-proof and comprehensive solution. What do you think? :-)

Contributor

anthonyfok commented Apr 27, 2016

@anthonyfok Could you prepare a patch to add the golang-any package to the golang source package please?

Sorry for the three-month delay. I finally filed a bug report with patch on the Debian BTS, see https://bugs.debian.org/822746.

However, it turns out that there has been new development: @mwhudson has created src:golang-defaults (similar to srd:gcc-defaults) which provides golang-any and allows the co-installation of multiple versions of Go. Please see his reply at https://bugs.debian.org/822746 as well as the following proposed changes in the Git repositories on Alioth:

I think @mwhudson's work is a more well-thought-out, future-proof and comprehensive solution. What do you think? :-)

Set Build-Depends to golang-any instead of golang-go
To allow the use of gccgo on architectures where golang-go is unavailable.

* For "-type program", Build-Depends on golang-any
* For "-type library", remove Depends on golang-go
@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Apr 28, 2016

Contributor

See also https://bugs.debian.org/818415: "golang: move to per-Go-major version coinstallable packages"

Contributor

anthonyfok commented Apr 28, 2016

See also https://bugs.debian.org/818415: "golang: move to per-Go-major version coinstallable packages"

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg May 1, 2016

Contributor

This looks good to me. However, golang-any is not yet in Debian (only in Ubuntu). Can you ping this PR once golang-any is in Debian? I鈥檒l gladly merge it then.

Contributor

stapelberg commented May 1, 2016

This looks good to me. However, golang-any is not yet in Debian (only in Ubuntu). Can you ping this PR once golang-any is in Debian? I鈥檒l gladly merge it then.

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jun 2, 2016

Contributor

Hi @stapelberg,

Can you ping this PR once golang-any is in Debian? I鈥檒l gladly merge it then.

Hurray! golang-any and friends have officially landed in Debian as of today (2016-06-02)! See https://bugs.debian.org/818415#30, as well as http://tracker.debian.org/pkg/golang-any (which redirects to http://tracker.debian.org/pkg/golang-defaults).

Contributor

anthonyfok commented Jun 2, 2016

Hi @stapelberg,

Can you ping this PR once golang-any is in Debian? I鈥檒l gladly merge it then.

Hurray! golang-any and friends have officially landed in Debian as of today (2016-06-02)! See https://bugs.debian.org/818415#30, as well as http://tracker.debian.org/pkg/golang-any (which redirects to http://tracker.debian.org/pkg/golang-defaults).

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jun 9, 2016

Contributor

Ping again? @stapelberg

Contributor

anthonyfok commented Jun 9, 2016

Ping again? @stapelberg

@glaubitz

This comment has been minimized.

Show comment
Hide comment
@glaubitz

glaubitz Jun 9, 2016

@anthonyfok Thanks for this working on this!

As a porter, I have actually been wondering how to get Go packages build on more architectures and whether any of the Go packages actually have hard-depends on golang. Very glad to hear that this is being sorted out now, great work!

PS: golang upstream actually wanted to raise the minimum instruction support for ppc64 (Big Endian) to POWER8 to be able to share more code between the ppc64el and ppc64 ports. But I was able to convince upstream to keep the ppc64be port compatible with POWER5 which means we will still be able to use golang on ppc64 even with Go 1.7 :).

glaubitz commented Jun 9, 2016

@anthonyfok Thanks for this working on this!

As a porter, I have actually been wondering how to get Go packages build on more architectures and whether any of the Go packages actually have hard-depends on golang. Very glad to hear that this is being sorted out now, great work!

PS: golang upstream actually wanted to raise the minimum instruction support for ppc64 (Big Endian) to POWER8 to be able to share more code between the ppc64el and ppc64 ports. But I was able to convince upstream to keep the ppc64be port compatible with POWER5 which means we will still be able to use golang on ppc64 even with Go 1.7 :).

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jun 9, 2016

Contributor

@anthonyfok Thanks for this working on this!

@glaubitz Thanks for the compliment, but the real credit goes to @mwhudson for revamping the golang packages to make golang-any happen. :-)

And thank you for convincing the upstream Go team to maintain backward compatibility with POWER5! ;-)

Contributor

anthonyfok commented Jun 9, 2016

@anthonyfok Thanks for this working on this!

@glaubitz Thanks for the compliment, but the real credit goes to @mwhudson for revamping the golang packages to make golang-any happen. :-)

And thank you for convincing the upstream Go team to maintain backward compatibility with POWER5! ;-)

@stapelberg stapelberg merged commit daafda0 into Debian:master Jun 15, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment