Фон
«Гарантирует ... установлен» просто означает, что это зависит от набора пакетов, которые фактически предоставляют Go dev. окр.
Как вы можете видеть, этот пакет зависит от трех других Пакеты- golang-1.8-doc, golang-1.8-go, golang-1.8-src-так при установке golang-1.8, те три будут установлены, а также.
Я должен признать, что проблема, с которой вы столкнулись, действительно запутанная, но ее легко объяснить.
Если вы посмотрите на список пакетов, установленных с помощьюgolang-1.8-go, вы увидите, что goинструмент установлен как /usr/lib/go-1.8/bin/go, а каталог /usr/lib/go-1.8/binне указан в PATHпеременной среды по умолчанию (установленной /etc/profile).
Причина, по которой это делается, двояка:
В
golang-X.Y*одном наборе Debian может быть несколько групп пакетов одновременно; скажем, у 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по умолчанию установлена версия среды выполнения Go для Stretch.
В другом выпуске golang-goбудет зависеть другой golang-X.Y-go пакет.
Именно этот пакет обеспечивает /usr/bin/goуказание на /usr/lib/go-1.7/bin/go.
Так что, если (и только если) вы golang-goустановили, будет ли у вас goдоступен бинарный файл /usr/bin, и это будет Go 1.7 в Stretch.
И нет, невозможно каким-либо образом принудительно golang-goуказать на goустановленный golang-1.8-goпакет, и нет способа выбрать предпочитаемую версию Go с помощью механизма «альтернативы dpkg».
Мое понимание «почему» этого подхода состоит в том, чтобы иметь известную версию goв любом выпуске Debian. Это предположительно необходимо для сборки пакетов программного обеспечения Debian, написанных на Go. В противном случае, для машин по сборке пакетов потребовалось бы изобрести некоторую хитрость для поиска версии Go по умолчанию; на данный момент их исходные пакеты могут зависеть golang-goи называть это днем.