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