We can improve the organization of some of our Go language packages in a way that will make it easier to use and maintain them, and will also more closely match the way they are developed and used upstream.
For example, take go-golang-org-x-crypto-pbkdf2 and go-golang-org-x-crypto-salsa20. These are libraries that can be imported into Go code independently of each other. However, they are both part of the upstream Git repository at <https://golang.org/x/crypto> and it's not idiomatic to distribute them separately, or to allow their versions to diverge. There are other consequences that are seriously unidiomatic, such as needing to make Guix packages for "internal" components that really should not be exposed at all. Overall, it complicates our Go packaging effort. The big difference for Guix packagers will be that these library collection meta-packages like x/crypto will not be compiled at all when they are "built" — they will just be source code. This is normal when developing Go software but it may obscure the dependency graph. Originally we chose to package these things separately because if you try to compile a Go program that imports one of them, but it can't be found, the error message specifically complains that the library is missing, not that the entire x/crypto Git repo is missing. I think that kind of "exploratory" packaging process, where you try to build a Guix package and add dependencies one at a time when the build fails, is pretty common, but it led us astray here. I'll push a Git branch 'go-consolidation' on Savannah soon and will push it to master soon-ish, pending your comments.
