☰

在 Debian 上使用非默认 golang 包安装的 Go

tag-icon • tag-icon debian package-management apt
在 Debian 上使用非默认 golang 包安装的 Go

我正在尝试安装 go 1.8。

除了 golang-1.7 之外的任何 apt 包都无法使用。Golang-1.7 可以正常安装，但 golang-1.8 则不行。repo 中的包是否错误/不完整？

Debian 声称 golang-1.8“此软件包是一个元包，安装后可保证安装（大部分）完整的 Go 开发环境。”https://packages.debian.org/stretch/golang-1.8 但这显然不是事实。

# apt install golang-1.8 golang-1.8-go
Reading package lists... Done
Building dependency tree
Reading state information... Done
golang-1.8 is already the newest version (1.8.1-1).
golang-1.8-go is already the newest version (1.8.1-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# go
bash: /usr/bin/go: No such file or directory
# whereis go
go:
# uname -a
Linux linux 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux
# cat /etc/debian_version 
9.4

答案1

背景

“保证…已安装”仅仅意味着它依靠在一组实际提供 Go dev.env 的包上。

正如你可以看到，这个包依赖于另外三个包—— golang-1.8-doc、、 ——所以当你安装时，这三个包也会被安装。golang-1.8-gogolang-1.8-srcgolang-1.8

我必须承认，您遇到的问题确实令人困惑，但可以轻松解释。

如果你看一下安装的软件包列表golang-1.8-go，您会看到该go工具安装为/usr/lib/go-1.8/bin/go，并且目录/usr/lib/go-1.8/bin未在默认PATH环境变量（由设置/etc/profile）中列出。

这样做的原因有两个：

  • 同一个 Debian 套件中可以golang-X.Y*同时存在多组软件包；比如 Stretch 有 1.7 和 1.8。

    至关重要的是要理解它们是可共同安装的，这可能有助于测试经过测试的项目如何X.Y与之一起工作X.Y+N。

  • Debian 提供了一个特殊的“最通用”的 Go 包，它依赖于一个特定的golang-X.Y包，该包被视为特定 Debian 版本的“标准”。

    在 Stretch 中，golang-go，如您所见，它的版本为“1.7”并且依赖于 golang-1.7-go。

    此软件包确保特定默认golang-X.Y-go软件包提供的可执行二进制文件在“标准位置”可用 - 在/usr/bin （你自己看）。

该怎么办呢？

有几种可能性：

  • 仅/usr/lib/go-1.8/bin/go通过其完整路径名调用。

    该go工具“知道”它GOROOT在哪里，所以它可以很好地找到特定于其版本的软件包。

  • 将该目录添加到路径变量中；比如说

     export PATH="/usr/lib/go-1.8/bin:$PATH"

    放入您的~/.bashrc脚本中，下次调用go将在新的位置找到它。

  • 获取包的源代码golang-go，修复它以使其成为golang-1.8-go默认包，构建它并安装。

    （我暂时不建议这么做。）

希望这可以帮助。

再次尝试解释

Stretch 有两包三种包装：golang-1.7-*和golang-1.8-*。

在每个包中，golang-1.N-go包都会将其go二进制文件安装在 下/usr/lib/go-1.N/bin。它们都没有安装符号链接在下面/usr/bin。

这样做的原因是为了让这些包裹可共同安装， 这样您就可以使用任何已安装的版本编译您的 Go 代码。

现在其他，独立的包，其名称中不编码 Go 发行版本。它被命名为golang-go，并且它仅golang-1.7-go 取决于1.7默认Stretch 的 Go 运行时版本。

在另一个版本中，golang-go将依赖于另一个golang-X.Y-go 包。

这是这包，它提供/usr/bin/go指向 /usr/lib/go-1.7/bin/go。

因此，如果（且仅当）您已经golang-go安装，您才会go在下获得二进制文件/usr/bin，并且它将是 Stretch 中的 Go 1.7。

并且，不可能以某种方式强制golang-go指向 go已安装的golang-1.8-go包，也无法通过“dpkg alternatives”机制选择首选的 Go 版本。

我认为采用这种方法的“原因”是，在任何给定的 Debian 版本中都有一个众所周知的版本go。这据说是构建用 Go 编写的 Debian 软件包所必需的。否则，软件包构建机制就需要发明一些技巧来找到 Go 的默认版本；截至目前，他们的源软件包可能只是依赖于 Go，然后就golang-go结束了。

相关内容