AFAIK, вам нужно добавить /usr/share/gocode к вашей переменной среды GOPATH (после вашего личного рабочего пространства Go, разделенного :), чтобы эти пакеты были доступны для go toolchain.
Пожалуйста, обратитесь к этому руководству (и посмотрите, что dpkg -L выводит для любого установленного Go пакета библиотеки, представляющего интерес - вы увидите, что путь импорта пакета действительно расположен под /usr/share/gocode/src).
(Чтобы подробнее рассказать о том, что @Flimzy предложил в своем комментарии к исходному сообщению, а @JimB расширился в своем…)
Возможно, вам потребуется четко сформулируйте для себя, в чем заключаются ваши намерения при разработке.
«Проблема» в том, что существует определенное замешательство в подходах Debian и Go к управлению зависимостями:
Общая практика, предлагаемая сообществом Go, состоит в том, чтобы либо исправить определенные версии ваших зависимостей (в наши дни - с помощью go модулей ), либо позволить инструментальной цепочке получить и установить их. или продавать свои зависимости - что логически одно и то же, но в этом случае вы фактически несете эти зависимости как часть своей кодовой базы (они просто находятся в определенном каталоге c).
первый предлагается для библиотечного кода и, как правило, кода, который предоставляется для повторного использования третьими сторонами, в то время как последний обычно используется в «конечных» продуктах (обычно разрабатываемых собственными силами).
Подход, принятый Debian, основан на интеграции : они по понятным причинам отвергают идею неконтролируемого встраивания зависимостей и стараются убедиться, что все, что «обратно зависимо» от чего-либо еще, правильно упаковано, и в идеале только единственная версия данной библиотеки существует в любом конкретном выпуске ОС (хотя это не всегда возможно в реальной жизни).
Ни один из подходов в конечном итоге не является «правильным», потому что они обслуживают для разных вариантов использования.
Важно учитывать, что большинство (i е не все) команды, пишущие отраслевой код на Go, рассматривают базовую ОС как скучную деталь реализации - например, blob «чего-то», что не слишком интересно и просто необходимо для запуска целевой продукт (в наши дни этот подход доведен до крайности за счет использования контейнеров) и самостоятельно управлять их зависимостями.
Почему это так?
Это философский вопрос. Я думаю, что это в основном сводится к общему отсутствию на предприятиях должным образом квалифицированных специалистов для правильной интеграции с целевой платформой, и в то же время - к простоте поддержки ваших собственных проверенных и проверенных версий ваших зависимостей, а не предоставленных. дистрибутивом.
Теперь давайте посмотрим на библиотеки Go, упакованные в Debian из другого региона.
Упаковщики Debian решают свою задачу интеграции c, упаковывая пакеты Go библиотек в способ, который делает их доступными для помощников сборки Debian (см. dh-golang). То есть в Debian, когда вы готовите пакет какой-то программы, написанной на Go, вы неизбежно будете использовать эту dh-golang вещь, которая гарантирует, что набор инструментов Go вызывается таким образом, чтобы он мог использовать установленные пакеты. .
Теперь примите во внимание, что довольно значительная часть кода библиотеки Go, и многие исполняемые программы не зависят от платформы c, и , если вы пишете код Go, который предназначен для общего использования и, следовательно, будут где-то опубликованы (например, в некоторых популярных Git хостинговых решениях), гораздо лучше сохранить код организованным таким образом, чтобы любой разработчик мог просто взять его и иметь возможность работать над без специальной подготовки.
Итак, я веду вас к тому, что, если вы не пишете код, который определенно будет использоваться в Debian, ваш подход может быть правильным, но если вы пишете «обычный «Код Go, я бы рекомендовал разделить задачи« написание + поддержка кода »и« интеграция с Debian »- то есть напишите свой код так, как рекомендует Go сообщество, а затем напишите пакет Debian, который использует установленные зависимости.
Обратите внимание, что для последнего вам может потребоваться фактически упаковать все недостающие зависимости.