[pkg-golang-devel] Bug#822746: golang: Add golang-any dependency package to install either golang-go or gccgo
foka at debian.org
Wed Apr 27 04:27:22 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
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?
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2441 bytes
Desc: not available
More information about the pkg-golang-devel