[devel] golang policy

[devel] golang policy

[Denis Pynkin]

Hi, 

А как у нас планируется работать с пакетами, написанными на Go?
Пакетить все зависимости в отдельные src или можно какие-то аналоги для
bundle, как предлагают в Fedora Project?

--
wbr,d4s

Re: [devel] golang policy

[Alexey Gladkov]

On Sun, Jan 31, 2016 at 06:33:30PM +0300, Denis Pynkin wrote:
> Hi, 
> 
> А как у нас планируется работать с пакетами, написанными на Go?
> Пакетить все зависимости в отдельные src или можно какие-то аналоги для
> bundle, как предлагают в Fedora Project?

Политика в многом схожая с Fedora. Не все пакеты несут зависимости с
собой (например в виде Godeps). Для таких проектов зависимости
пакетируются.

Буквально вчера в сизиф пошёл новый golang и rpm-build-golang, где была
предпринята попытка упорядочить зоопарк golang-пакетов.

Если есть идеи по этому поводу рад буду обсудить ))

-- 
Rgrds, legion

Re: [devel] golang policy

[Denis Pynkin]

On Mon, Feb 01, 2016 at 08:36:28AM +0100, Alexey Gladkov wrote:
> > А как у нас планируется работать с пакетами, написанными на Go?
> > Пакетить все зависимости в отдельные src или можно какие-то аналоги для
> > bundle, как предлагают в Fedora Project?
> 
> Политика в многом схожая с Fedora. Не все пакеты несут зависимости с
> собой (например в виде Godeps). Для таких проектов зависимости
> пакетируются.

к своему стыду, не знал про godeps.
Я правильно понимаю, что godeps поможет в создании bundle либо отдельных
пакетиков с зависимостями?

> Буквально вчера в сизиф пошёл новый golang и rpm-build-golang, где была
> предпринята попытка упорядочить зоопарк golang-пакетов.

пока не пришло. ждем-с в репозитории.

> Если есть идеи по этому поводу рад буду обсудить ))

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

Рано или поздно появятся пакеты, которым нужна одна и та же зависимость,
но разных версий (и разным API) :( 
В рамках bundle это решается легко, с распиленными на кусочки 
зависимостями -- уже сложнее.

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

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

ЗЫ буду рад, если окажется что по поводу bundle я заблуждаюсь.

--
wbr,d4s

Re: [devel] golang policy

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Mon, Feb 01, 2016 at 06:29:22PM +0300, Denis Pynkin wrote:
[...]
> Еще вопрос -- поддерживает ли наш rpm зависимости вида:
> BuildRequires: golang(github.com/gorilla/context) ?

$ rpmquery --provides perl-base | grep -E '([^/]*/){2,}'
perl(Config/Perl/V.pm) = 0.240
perl(File/Spec/Functions.pm) = 3.560
perl(File/Spec/Unix.pm) = 3.560
perl(Hash/Util/FieldHash.pm) = 1.150
perl(IO/Socket/INET.pm) = 1.350
perl(IO/Socket/UNIX.pm) = 1.260
perl(List/Util/XS.pm) = 1.410
perl(PerlIO/via/QuotedPrint.pm) = 0.080
perl(Tie/Hash/NamedCapture.pm) = 0.090


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [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

Re: [devel] golang policy

[Denis Pynkin]

On Mon, Feb 01, 2016 at 05:27:04PM +0100, Alexey Gladkov wrote:

> > Дальше, не совсем понятно, как работать с исходниками в случае bundle.
> > Пока пришел к выводу, что собственно код программы -- калька из апстрима,
> > а все зависимости в отдельный гит, по сути снапшотом, и отдельным bundle пакетом,
> > который провайдит только bundle-пакет.
> 
> Я пока тоже не имею однозначного мнения на этот счёт. Если и делать
> bundle-пакет или bundle-бранч, то через godep, чтобы можно было
> автоматизировать проверку этих зависимостей.
> 
> > Еще вопрос -- поддерживает ли наш rpm зависимости вида:
> > BuildRequires: golang(github.com/gorilla/context) ?
> 
> Да. Я рассматривал этот вариант как основной.

пока пробую резать на пакетики, но что-то я не совсем понимаю, что
у нас с путями для golang

Например, упаковал я, пользуясь примерами, github.com/gorilla/websocket в пакет
golang-github-gorilla-websocket-devel и вижу, что все файлы *.go кладутся по
пути: /usr/share/gocode/src/github.com/gorilla/websocket

а при сборке зависимого от него пакета вижу ошибку:

+ /usr/share/golang/golang-build lxc
exec.go:11:2: cannot find package "github.com/gorilla/websocket" in any of:
  /usr/lib64/golang/src/github.com/gorilla/websocket (from $GOROOT)
  /usr/src/RPM/BUILD/lxd-2.0.0/.build/src/github.com/gorilla/websocket (from $GOPATH)

почему у нас игнорируется /usr/share/gocode?

Кривохак в %build в виде "export GOPATH="%go_path:$BUILDDIR"" работает, но
мне кажется, что это лучше поправить в rpm-build-golang.

Или я где-то что-то недопонимаю?

--
wbr,d4s

Re: [devel] golang policy

[Alexey Gladkov]

On Tue, Feb 16, 2016 at 03:51:55PM +0300, Denis Pynkin wrote:
> пока пробую резать на пакетики, но что-то я не совсем понимаю, что
> у нас с путями для golang
> 
> Например, упаковал я, пользуясь примерами, github.com/gorilla/websocket в пакет
> golang-github-gorilla-websocket-devel и вижу, что все файлы *.go кладутся по
> пути: /usr/share/gocode/src/github.com/gorilla/websocket
> 
> а при сборке зависимого от него пакета вижу ошибку:
> 
> + /usr/share/golang/golang-build lxc
> exec.go:11:2: cannot find package "github.com/gorilla/websocket" in any of:
>   /usr/lib64/golang/src/github.com/gorilla/websocket (from $GOROOT)
>   /usr/src/RPM/BUILD/lxd-2.0.0/.build/src/github.com/gorilla/websocket (from $GOPATH)
> 
> почему у нас игнорируется /usr/share/gocode?
> 
> Кривохак в %build в виде "export GOPATH="%go_path:$BUILDDIR"" работает, но
> мне кажется, что это лучше поправить в rpm-build-golang.
> 
> Или я где-то что-то недопонимаю?

Путь для системных модулей /usr/lib64/golang, для сторонних библиотек
используется /usr/share/gocode, который нужно добавлять GOPATH (как вы и
сделали). Класть src в архитектурно зависимую директорию не имеет.

-- 
Rgrds, legion

Re: [devel] golang policy

[Ildar Mulyukov]

On Mon, Feb 1, 2016 at 10:38 AM Denis Pynkin <denis.pynkin@gmail.com> wrote:
> А как у нас планируется работать с пакетами, написанными на Go?
> Пакетить все зависимости в отдельные src или можно какие-то аналоги для
> bundle, как предлагают в Fedora Project?

Коллеги,
какие у нас новости на эту тему? мне кажется, собирать по пакету на
каждую зависимость --- нереальный объём. Тут только роботы, возможно,
справятся.
Какие у нас варианты?
Спасибо. С уважением, Ильдар
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
GoogleTalk: ildar.mulyukov@gmail.com
blog: http://johan-notes.blogspot.com/

Re: [devel] golang policy

[Anton Farygin]

On 28.12.2019 15:40, Alexey Shabalin wrote:
>
>
> пт, 13 дек. 2019 г., 10:22 Ildar Mulyukov <ildar.mulyukov@gmail.com>:
>
>     On Mon, Feb 1, 2016 at 10:38 AM Denis Pynkin
>     <denis.pynkin@gmail.com> wrote:
>     > А как у нас планируется работать с пакетами, написанными на Go?
>     > Пакетить все зависимости в отдельные src или можно какие-то
>     аналоги для
>     > bundle, как предлагают в Fedora Project?
>
>     Коллеги,
>     какие у нас новости на эту тему? мне кажется, собирать по пакету на
>     каждую зависимость --- нереальный объём. Тут только роботы, возможно,
>     справятся.
>     Какие у нас варианты?
>     Спасибо. С уважением, Ильдар
>
>
> Упаковываем зависимости вместе с пакетом(вендоризируем - складываем в 
> vendor). На каждую зависимость делать отдельный пакет нет смысла.
> Примеры можно посмотреть в пакетах telegraf, traefik(в спеке есть 
> инструкция по подготовке к вендоризации).
> Для вендоризации используеются:
> - dep ensure -vendor-only (для старых проектов)
> - go mod vendor (для проектов, которые перешли на новую схему)

Вообще про policy хороший вопрос.

Понадобилось мне упаковать утилиту, написанную на go.

по примеру из других пакетов vendor я сделал и утилита собирается.

Но в других пакетах есть какие-то странные вещи типа %golang_prepare

В нём делается:

$ rpm --eval %golang_prepare
/usr/share/golang/golang-prepare

Который вообще делает что-то такое:

#!/bin/sh -eu

BUILDDIR="${BUILDDIR?}"
IMPORT_PATH="${IMPORT_PATH?}"

mkdir-vp--"$BUILDDIR/src/$IMPORT_PATH"
cp-alv--* "$BUILDDIR/src/$IMPORT_PATH"

Никакой документации на предмет того, что принято писать в BUILDDIR и 
IMPORT_PATH я не нашёл.