1

Я пытаюсь установить go 1.8.

Apt-пакет всего, кроме golang-1.7, не работает. Golang-1.7 устанавливается правильно, golang-1.8 нет. Является ли пакет в репо неправильным / неполным?

Заявления 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 ответ1

2

Фон

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .