I just recently installed a piece of software written in Go, from source, on Ubuntu 14.04. It wasn't so nice for a non-Go-programmer.
The instructions wanted me to download a binary tarball of Go and untar it directly into /usr/local. As if I would never need to uninstall it. Apparently even though the version of Go has changed several times since Ubuntu packaged it, they think this will be the last version ever, or something?
I ended up hunting for an Ubuntu PPA that had it instead. Of course all the accepted answers on Stack Overflow point to PPAs that don't exist anymore. A comment sitting at some tragically low score saying "hey, try this one instead?" pointed me to something that worked.
I think you dealt with it the first time and you've gotten used to it. (And maybe there's some nice way to get a newer version of Go when you already have Go.)
OOI, is godeb[0] the something that worked? It "transforms upstream tarballs for the Go language in deb packages and installs them". It's always worked well for me.
For reference, I'm referring to the directions you get at the top of the search results when you type "installing go on ubuntu" into Google.
The directions link to Stack Overflow, though I don't know how the search result picked out these steps, as Stack Overflow has a different accepted answer that doesn't work. Intervention by Google, possibly?
I didn't realize it would only make one directory. That is reassuring. I would still prefer packages as a way to install, upgrade, and remove Go, instead of remembering months from now that Go is installed differently from everything else and there's this directory I need to mess with.
Now, that all would have been more intuitive as something to do in my home directory. If it only needs one directory and it can go anywhere, why would these Google-blessed directions tell me to mess with /usr/local? I believe you, I just assumed that people would be averse to messing with system files without a package if there were any other option.
(I think of Python, where the one thing you're supposed to do with your system Python is use virtualenv to install a non-system Python. Which is another example of something that's only clear to veterans of the language.)
Now... this is a problem with a whole lot of programming languages. Programming languages change. Their libraries change way too fast for an OS-approved package manager to keep up, so you need a package manager for your language. And that changes too, and nobody designs their packaging system to smoothly update to a better packaging system designed by someone else.
Maybe one day every programming language and OS will unite under one purely functional packaging system and never replace it... haha, no.
