From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DNS_FROM_AHBL_RHSBL autolearn=no autolearn_force=no version=3.4.0 Date: Mon, 1 Feb 2016 17:27:04 +0100 From: Alexey Gladkov To: Denis Pynkin Message-ID: <20160201162704.GE15721@comp-core-i7-2640m-0182e6.fortress> References: <20160131153330.GA32237@epbyminw3061.minsk.epam.com> <20160201073628.GB15721@comp-core-i7-2640m-0182e6.fortress> <20160201152922.GA29360@epbyminw3061.minsk.epam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160201152922.GA29360@epbyminw3061.minsk.epam.com> Cc: ALT Linux Team development discussions Subject: Re: [devel] golang policy X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:25:47 -0000 Archived-At: List-Archive: List-Post: 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