[pkg-golang-devel] Bug#822746: golang: Add golang-any dependency package to install either golang-go or gccgo

Anthony Fok foka at debian.org
Wed Apr 27 04:27:22 UTC 2016

Source: golang
Severity: normal
Tags: patch

Hash: SHA256

In order to make Go packages available on as many architectures as
possible, we can make these packages depend on gccgo on architectures
where golang-go is not yet available.

Initially, I suggested patching dh-make-golang to expand the
Build-Depends field in the automatically generated debian/control
template for Go programs (dh-make-golang -type program)like so:

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

However, that would mean a massive effort in updating many such packages
every time golang-go supports a new architecture.

As per discussion at https://github.com/Debian/dh-make-golang/pull/36
on GitHub, it was decided that a golang-any package should be created
in src:golang instead, so for Go program-type packages that need it,
a simple "Build-Depends: golang-any" suffices in providing the default
Go compiler for each architecture.

Excerpts from our earlier discussion on GitHub:

> It’s a bit unfortunate that we’d have to maintain the list of
> architectures if we merged this pull request. Especially since it might
> change in the future, and then we’d need to update all our packages. I’m
> not saying this isn’t doable, but I’m 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 (foka):
> 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.
> ...
> 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
> @tianon @paultag Do you agree to have golang-any in src:golang?

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

> 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.

> 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?

Attached is the patch to do so.  It has been tested on my amd64 laptop
and on zelenka.debian.org (s390x porterbox).



- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

- -- no debconf information

Version: GnuPG v1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_golang-any_package.patch
Type: text/x-diff
Size: 2441 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-golang-devel/attachments/20160427/555c8419/attachment.patch>

More information about the pkg-golang-devel mailing list