Bug#842254: [pkg-golang-devel] Bug#842254: Bug#842254: Bug#842254: Bug#842254: please allow to use gccgo on architectures providing golang

2016-11-20 Thread Michael Hudson-Doyle 
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

2016-11-20 Thread Tianon Gravi 
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