/cc @adg

If you need help with an apt-repo, please ping me.

You can do what you like under /opt/YOUR_PRODUCT in Linux, as that has much less restrictions. see http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES for details.

Sounds fine to me.

On 27 May 2015 at 14:17, Minux Ma notifications@github.com wrote:

If installing into /opt/go is acceptable, then fixing the issue is quite
trivial.

We can make misc/makerelease also package deb and rpm.

—
Reply to this email directly or view it on GitHub
#10965 (comment).

Do we need to do anything special to offer an apt repository?

On 27 May 2015 at 15:32, Andrew Gerrand adg@golang.org wrote:

Sounds fine to me.

On 27 May 2015 at 14:17, Minux Ma notifications@github.com wrote:

If installing into /opt/go is acceptable, then fixing the issue is quite
trivial.

We can make misc/makerelease also package deb and rpm.

—
Reply to this email directly or view it on GitHub
#10965 (comment).

Reminder that godeb exists for turning Go binary tarballs into debs.

How does the train of trust for the gpg key work?

On 28 May 2015 at 22:31, Minux Ma notifications@github.com wrote:

Yes, I'm aware of godeb. Releasing official deb/rpm is still
desirable because Google can sign the rpm/deb package
(I hope, at least the OS X pkgs are signed, so if we started
distributing rpm/deb, they could be signed as well.)

@adg, do you think we can sign the deb/rpm?
(They need to be signed by a gpg key)

—
Reply to this email directly or view it on GitHub
#10965 (comment).

For the apt trust mechanism, apt-secure(8) provides a good explanation.

It may be possible; I'll find out what's involved in doing that.

On 29 May 2015 at 14:50, Minux Ma notifications@github.com wrote:

Is it possible for us to sign the Go packages the same as the official
Chrome packages? (I.e. sign with the Google Inc. Linux Package Signing Key)

—
Reply to this email directly or view it on GitHub
#10965 (comment).

FWIW, https://github.com/jordansissel/fpm (not in Go, but who knows..)

No time. Let's reconsider this for Go 1.6.

@mwhudson do you use a tool to prepare the golang packages for debian/ubuntu? As a step toward providing Google-signed, current debs, is it possible to roll that functionality into the x/build/cmd/release tool?

No, not really. Unpack tarball, copy debian directory in, fiddle as needed, test build, upload. I made a silly shell script to help making a deb from git tip: http://paste.ubuntu.com/14677806/ but I guess that's not really what you are talking about?

Debian maintains their packaging in git http://anonscm.debian.org/cgit/pkg-golang/golang.git and uses git-buildpackage to update to a new upstream version.

For adding the functionality to x/build/cmd/release I guess the question would be "where do you get the debian directory from?". I suppose it could just be embedded into cmd/release. It would be nice to coordinate between any official Google debs and Ubuntu and Debian, but I guess I can just submit CLs/PRs/patches to wherever you end up pulling the packaging bits from :-)

I wanna help! The easiest way would be to create a separate repo for the deb stuff and use git-buildpackage. I wanna do it! I can make a sample repo up tomorrow as a POC for you all ;)

@jfrazelle cool! Let me know if you need any pointers within our release infrastructure.

@jfrazelle are you planning on basing your work on the existing debian/ubuntu packages?

Yeah I think that would make the most sense

On Wed, Mar 2, 2016 at 1:04 PM, Michael Hudson-Doyle <
notifications@github.com> wrote:

@jfrazelle https://github.com/jfrazelle are you planning on basing your
work on the existing debian/ubuntu packages?

—
Reply to this email directly or view it on GitHub
#10965 (comment).

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

deb http://dl.google.com/linux/go/deb/ stable main (like http://dl.google.com/linux/chrome/deb/) would be very useful.

@jfrazelle I'm looping back on this now. Did you make any progress?

Oh gosh so sorry got caught up in something else will try and find some
time over the weekend

On Thursday, March 31, 2016, Andrew Gerrand notifications@github.com
wrote:

@jfrazelle https://github.com/jfrazelle I'm looping back on this now.
Did you make any progress?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#10965 (comment)

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

FWIW, I've made some changes in Ubuntu recently, partly in support of having multiple Go versions installed at once, and I'm planning on getting similar changes into Debian too. My stuff is all in

https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/

and

https://git.launchpad.net/~mwhudson/ubuntu/+source/golang-defaults/+git/xenial

@jfrazelle no worries.

I've been thinking about what the final form of these packages should be.

IIUC, the Debian packaging guidelines are what gave us the multiple packages today: golang-go, golang-doc,golang-src`, etc.

Do we want to be shipping multiple packages from our official apt repository? For simplicity's sake, it makes sense to me to provide a single golang package, which is more or less equivalent to untarring to /usr/local/go and updating PATH.

The major downside of this is that some users will get more than they want or need. For instance, everyone on amd64 would get the race-detector-enabled runtime and standard library. But to me that doesn't seem a significant drawback.

@mwhudson, @jfrazelle what do you think about this?

I feel like it's more like a benefit but what we can do is have a minimal
package and have that "reccomend" installing golang-doc etc so if you
install with apt-get install --no-install-recommends you get minimal other
wise you get the whole thing

On Thursday, March 31, 2016, Andrew Gerrand notifications@github.com
wrote:

@jfrazelle https://github.com/jfrazelle no worries.

I've been thinking about what the final form of these packages should be.

IIUC, the Debian packaging guidelines are what gave us the multiple
packages today: golang-go, golang-doc,golang-src`, etc.

Do we want to be shipping multiple packages from our official apt
repository? For simplicity's sake, it makes sense to me to provide a single
golang package, which is more or less equivalent to untarring to
/usr/local/go and updating PATH.

The major downside of this is that some users will get more than they want
or need. For instance, everyone on amd64 would get the
race-detector-enabled runtime and standard library. But to me that doesn't
seem a significant drawback.

@mwhudson https://github.com/mwhudson, @jfrazelle
https://github.com/jfrazelle what do you think about this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#10965 (comment)

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

FWIW, I've now made Go 1.4, 1.5, 1.6 and tip packages for supported Ubuntu releases (I presume they'd build fine in Debian too, but I haven't checked): https://launchpad.net/~gophers/+archive/ubuntu/testing

I have a slightly complicated git (-buildpackage) based approach for making these, which you can find in https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/. It's all based on the ubuntu-xenial branch (which has 1.6 in it currently), and then there are ppa-golang-1.4, ppa-golang-1.5 and ppa-golang-1.7 branches based on that. (The golang-1.7 packages use a launchpad feature called a "source package recipe" to glom the 1.7 debian directory from the packaging branch together with the source from a mirror of the Go repo: https://code.launchpad.net/~mwhudson/+recipe/golang-daily).

Do you think these would be suitable as a base for the "official" packages? If you don't get around to making official packages for a while, would you be open to linking to this archive (or well, the one I plan on creating after people have tested these) from the install docs?

I think the distros have this well in hand, and would be inclined to close this issue. I'm not able to work on it myself.

It seems there's no desire to do this.

and would be inclined to close this issue.

Closing, then.