Subject: Re: [GOST]Установка пакета gogost

From: Sergey Matveev <[email-masked]>
Date: Tue, 15 Nov 2016 21:59:55 +0300

*** Phil Kulin <[email-masked]> [2016-11-15 15:30]:
>А почему такая странная установка gogost? Почему нельзя сделать, чтобы
>хотя бы откуда-то он ставился штатными методами самого Go?

Это речь про go get?

* они не позволяют зафиксировать/указать нужный коммит/тэг, насколько
  помню -- каждый вызов go get может скачать другую версию кода. Это не
  допустимо для детерминированных сборок
* они не позволяют указать разные URL репозиториев. Задаётся только
  что-то одно, типа github.com/foo/bar. Если эта централизованная точка
  получения кода падает -- сборку провести нельзя, не поменяв go get
  аргументы. Хотя это можно решить Makefile-ами которые будут дёргать то
  одну команду, то другую
* если появится какая-нибудь собираемая документация, типа Texinfo или
  Sphinx, то склонировав репозиторий, пользователь библиотеки не
  получает её в собранном в готовом виде. Заставлять его иметь у себя
  сборочную систему для документации я считаю не хорошо. То есть, во
  время релизов нужно как-то где-то предоставлять собранную
  документацию. Кроме того, если появляются зависимости от других
  програм, то наверняка это будет какой-то git submodule, но который
  ссылается тоже на какой-то один URL и он может лежать и просто
  склонировав gogost репозиторий и забыв сделать git submodule update --
  человек не получит у себя на жёстком диске что-то целостное. То есть:
  исходный код разработчика это исходный код разработчика, а исходный
  код готовой библиотеки -- это уже другое. Иметь в репозитории
  полностью всю собранную документацию и копию всех зависимостей
  закоммиченную -- само собой отвратительно и не красиво
* go get не предоставляет возможностей криптографической аутентификации
  скачанного кода. Управлять и "передавать" доверие в нём нельзя.
  Предоставляемые мной tarball-ы подписаны и доверие (.sig) может
  распространяться и дальше, без online-а или PKI какого-нибудь

В общем это это гибче и надёжнее.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF