Bug#842254: [pkg-golang-devel] Bug#842254: Bug#842254: Bug#842254: Bug#842254: please allow to use gccgo on architectures providing golang
On 21 November 2016 at 16:33, Tianon Gravi wrote: > On 20 November 2016 at 13:42, Michael Hudson-Doyle > wrote: > > Having thought about it for a while, I think that this approach is OK, > and > > we can remove the unnecessary Depends: from the -dev binary packages over > > time. AIUI I'll need a sponsor to upload this change though as it'll go > > through NEW, anyone keen? :) > > I'm happy to review/sponsor if you think it's sane! > Check out mwhudson/add-gccgo-go in the golang-defaults repo :) > To be clear, you're talking about adding a new "gccgo-go" virtual > binary package to "src:golang-defaults" which satisfies requests for > "golang-go" via Provides (and thus also provides "/usr/bin/go" via > alternatives or Conflicts)? I took out the Provides: bit for now, it seemed a bit icky, but yes. > Will this simplify the logic behind "golang-any"? > Yeah. Actually, more than I had realised! Also pushed to my branch. Cheers, mwh
Bug#842254: [pkg-golang-devel] Bug#842254: Bug#842254: Bug#842254: Bug#842254: please allow to use gccgo on architectures providing golang
On 20 November 2016 at 19:45, Michael Hudson-Doyle wrote: > Check out mwhudson/add-gccgo-go in the golang-defaults repo :) Nice! My only question after taking a look at the diff is whether our "gccgo-go" relation on "golang-any" should be "(>= ${source:Version})", same as our "golang-go" relation? >> To be clear, you're talking about adding a new "gccgo-go" virtual >> binary package to "src:golang-defaults" which satisfies requests for >> "golang-go" via Provides (and thus also provides "/usr/bin/go" via >> alternatives or Conflicts)? > > I took out the Provides: bit for now, it seemed a bit icky, but yes. Yeah, agreed, especially since switching to "golang-any" is supposed to be the official way package maintainers can advertize that they support gccgo properly. I wonder how many packages currently depend on "golang-go" explicitly rather than "golang-any". >> Will this simplify the logic behind "golang-any"? > > Yeah. Actually, more than I had realised! Also pushed to my branch. Very nice; love how much simpler this is in that regard! Cheers! ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4