Фон
«Гарантирует ... установлен» просто означает, что это зависит от набора пакетов, которые фактически предоставляют 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).
Причина, по которой это делается, двояка:
В одном наборе 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 - версия по умолчанию среды выполнения 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 и называть это днем.
