[devel] golang policy

[Alexey Gladkov]

On Mon, Feb 01, 2016 at 06:29:22PM +0300, Denis Pynkin wrote:
> к своему стыду, не знал про godeps.
> Я правильно понимаю, что godeps поможет в создании bundle либо отдельных
> пакетиков с зависимостями?

Godeps (github.com/tools/godep) способ зафиксировать конкретные ревизии у
зависимостей в go.

Другой способ для разработчика библиотеки на go зафиксировать ревизию это
использовать gopkg.in .

> Собственно, мозговой штурм сегодня привел меня к безрадостному заключению,
> что bundle зависимостей для каждого пакета go, чуть ли не единственый
> выход. У нас же нет жесткого bundling policy?
> С т.з. безопасности меня это очень напрягает, откровенно говоря.
> 
> Рано или поздно появятся пакеты, которым нужна одна и та же зависимость,
> но разных версий (и разным API) :( 

По задумке создателей go библиотеки должны быть всегда обратно совместимы
или же import path должен быть изменён ))

> В рамках bundle это решается легко, с распиленными на кусочки 
> зависимостями -- уже сложнее.

Зато так легче отслеживать где и какой ревизии библиотека используется в
дистрибутиве. Особенно это важно т.к. после сборки нет возможности узнать
из чего была собрана программа на go.

Представьте решение задачи с bundle по устранению уязвимости в
golang.org/x/crypto/ssh. Кто с этим модулем собран и с какой ревизией.

> Дальше, не совсем понятно, как работать с исходниками в случае bundle.
> Пока пришел к выводу, что собственно код программы -- калька из апстрима,
> а все зависимости в отдельный гит, по сути снапшотом, и отдельным bundle пакетом,
> который провайдит только bundle-пакет.

Я пока тоже не имею однозначного мнения на этот счёт. Если и делать
bundle-пакет или bundle-бранч, то через godep, чтобы можно было
автоматизировать проверку этих зависимостей.

> Еще вопрос -- поддерживает ли наш rpm зависимости вида:
> BuildRequires: golang(github.com/gorilla/context) ?

Да. Я рассматривал этот вариант как основной.

-- 
Rgrds, legion