Hintergrund
«Garantien ... ist installiert» bedeutet lediglich, dass es von einer Reihe von Paketen abhängt, die Go Dev tatsächlich bereitstellen. env.
Wie Sie sehen können, hängt dieses Paket auf drei anderen Pakete- golang-1.8-doc, golang-1.8-go, golang-1.8-src-so wenn Sie installieren golang-1.8, werden diese drei auch installiert werden.
Ich muss zugeben, dass das Problem, das Sie haben, zwar verwirrend ist, aber leicht erklärt werden kann.
Wenn Sie sich die Liste der installierten Paketegolang-1.8-go ansehen, werden Sie feststellen, dass das goTool installiert /usr/lib/go-1.8/bin/goist und das Verzeichnis /usr/lib/go-1.8/binnicht in der Standardumgebungsvariablen aufgeführt PATHist (gesetzt durch /etc/profile).
Es gibt zwei Gründe, warum es so gemacht wird:
Es können mehrere Gruppen von
golang-X.Y*Paketen gleichzeitig in derselben Debian-Suite vorhanden sein. sagen wir, Stretch hat 1,7 und 1,8.Es ist wichtig zu verstehen, dass sie gemeinsam installiert werden können. Dies kann nützlich sein, um zu testen, wie ein Projekt
X.Yfunktioniert, mit dem getestet wurdeX.Y+N.Debian stellt ein spezielles "generischstes" Go-Paket zur Verfügung, das von einem bestimmten
golang-X.YPaket abhängt, das als "Standard" für das Debian-Release von Besonderen gilt.In Stretch ist es
golang-go, und wie Sie sehen können, hat es "1.7" in seiner Version und hängt davon abgolang-1.7-go.Dieses Paket stellt sicher, dass die ausführbaren Binärdateien, die von einem bestimmten Standardpaket
golang-X.Y-gobereitgestellt werden, unter "Standard" abgelegt werden können/usr/bin( siehe unter " Weitere Informationen" ).
Was ist dagegen zu tun?
Mehrere möglichkeiten:
Rufe nur
/usr/lib/go-1.8/bin/gomit vollem Pfadnamen auf.Das
goTool "weiß", wo es sichGOROOTbefindet, so dass es seine für seine Version spezifischen Pakete gut findet.Fügen Sie dieses Verzeichnis Ihrer Pfadvariablen vor. sag mal so was
export PATH="/usr/lib/go-1.8/bin:$PATH"In Ihr
~/.bashrcSkript und den nächsten Aufrufgofinden Sie es an der neuen Stelle.Holen Sie sich die Quelle des
golang-goPakets, korrigieren Sie es, sodass esgolang-1.8-godas Standardpaket ist, erstellen Sie es und installieren Sie es.(Ich würde es noch nicht empfehlen, diesen Weg zu gehen.)
Hoffe das hilft.
Noch ein Stich zum Erklären
Stretch hat zwei Packungen mit drei Paketen: golang-1.7-*und golang-1.8-*.
In jedem Pack golang-1.N-goinstalliert das Paket seine goBinärdatei unter /usr/lib/go-1.N/bin. Keiner von ihnen installiert einen Symlink unter /usr/bin.
Der Grund dafür ist, diese Paketpakete gemeinsam installierbar zu machen, sodass Sie Ihren Go-Code mit jeder installierten Version kompilieren können.
Nun gibt es ein weiteres unabhängiges Paket, das die Go-Release-Version nicht in ihrem Namen codiert. Es wird benannt golang-gound hängt nur davon ab, golang-1.7-go wo 1.7sich die Standardversion von Go Runtime für Stretch befindet.
In einer anderen Version golang-gohängt ein anderes golang-X.Y-go Paket ab.
Es ist dieses Paket, das auf /usr/bin/gozeigt /usr/lib/go-1.7/bin/go.
Wenn (und nur wenn) Sie golang-goinstalliert haben, haben Sie dann das goBinärprogramm zur Verfügung /usr/bin, und das wird von Go 1.7 in Stretch sein.
Und nein, es ist nicht möglich, irgendwie zu zwingen, golang-gozu Punkt goaus dem installierten golang-1.8-goPaket, und weder ist es eine Möglichkeit, eine bevorzugte Go - Version über den „dpkg Alternativen“ Mechanismus auszuwählen.
Mein Verständnis für das "Warum" dieses Ansatzes besteht darin, eine bekannte Version von goDebian in einer bestimmten Version zu haben. Dies ist vermutlich erforderlich, um Debian-Pakete von in Go geschriebenen Softwarepaketen zu erstellen. Andernfalls wäre es für Verpackungsmaschinen erforderlich, einige Tricksereien zu entwickeln, um die Standardversion von Go zu finden. Bis jetzt können ihre Quellpakete davon abhängen golang-gound täglich aufgerufen werden.