web-dev-qa-db-ja.com

Debianでデフォルト以外のgolangパッケージによってインストールされたGoを使用する

Go1.8をインストールしようとしています。

Golang-1.7以外のaptパッケージは機能しません。 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
debianpackage-managementapt
2
user6329530

バックグラウンド

"保証…がインストールされている"とは、実際にGo devを提供する一連のパッケージに依存することを意味します。環境.

表示 のように、このパッケージは他の3つのパッケージ（golang-1.8-doc、golang-1.8-go、golang-1.8-src）に依存しているため、golang-1.8をインストールすると、これら3つが同様にインストールされます。

あなたが経験している問題は、確かに紛らわしいことですが、簡単に説明できることを認めなければなりません。

golang-1.8-goによってインストールされたパッケージのリスト を見ると、goツールが/usr/lib/go-1.8/bin/goとしてインストールされていることがわかります。 /usr/lib/go-1.8/binはデフォルトのPATH環境変数（/etc/profileで設定）にリストされていません。

このように行われる理由は2つあります。

  • 同じDebianスイートに同時にgolang-X.Y*パッケージの複数のグループが存在する可能性があります。たとえば、Stretchには1.7と1.8があります。

    これらは同時インストール可能であることを理解することが重要です。これは、X.Yに対してテストされたプロジェクトがX.Y+Nでどのように機能するかをテストするのに役立つ場合があります。

  • Debianは、特定のDebianリリースの「標準」と見なされた特定のgolang-X.Yパッケージに依存する特別な「最も一般的な」Goパッケージを提供します。

    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-*の3つのパッケージの2つのパックがあります。

それぞれのパックで、golang-1.N-goパッケージはそのgoバイナリを/usr/lib/go-1.N/binの下にインストールします。 どちらも/usr/binの下にシンボリックリンクをインストールしません。

これは、これらのパッケージのパックを同時インストール可能にして、インストールされている任意のバージョンでGoコードをコンパイルできるようにするためです。

現在、別の独立したパッケージがあり、その名前にGoリリースバージョンがエンコードされていません。これはgolang-goという名前で、golang-1.7-goにのみ依存します。ここで、1.7はGoランタイムのdefaultバージョンです。ストレッチ。

別のリリースでは、golang-goは別のgolang-X.Y-goパッケージに依存します。

これはthisパッケージであり、/usr/bin/goを指す/usr/lib/go-1.7/bin/goを提供します。

したがって、golang-goがインストールされている場合（およびその場合のみ）、/usr/binでgoバイナリを使用できますか？これは、StretchのGo1.7になります。

いいえ、インストールされたgolang-goパッケージからgolang-1.8-goがgoを指すように強制することはできません。また、「dpkgalternatives」を介して優先Goバージョンを選択する方法もありません。 「メカニズム。

このアプローチの「理由」についての私の見解は、特定のDebianリリースにgoのよく知られたバージョンを含めることです。これは、Goで記述されたソフトウェアのDebianパッケージを構築するためにおそらく必要です。そうでなければ、パッケージ構築機械は、Goのデフォルトバージョンを見つけるためのいくつかのトリックを発明する必要があります。今のところ、それらのソースパッケージはgolang-goに依存していて、それを1日と呼んでいる可能性があります。

4
kostix