Опакечивание Go

Мне в целом не лень скачать бинарную сборку Go 1.7 и засандалить ее прямо в pkg_1-1.debian.tar.xz, потом скриптами распаковывать и юзать для сборки пакета

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

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

osc дает чистый chroot с нужным дистром. Что у этого дистра в stable лежит - то и берется. там особо не подготовишь

Тогда, если нет специфичного для osc способа поставить нужный пакет (типа указать его в BuildRequires или скачать при конфигурации). то выхода у тебя нет. Но класть компилятор в пакет с исходниками - это чудовищный костыль.

Но класть компилятор в пакет с исходниками - это чудовищный костыль.

капитан... да знаю я что это дико. но варианта который бы удовлетворял все дистры (скажем в бубунте 16.04 можно и из stable взять, а вот в 15.10 уже нет) я не нашел

вообще osc довольно убойная штука когда надо опакечивать языки типа Go или ноды. Там фишка что интернетов у chroot'а нет от слова совсем. Потом никакого go get, никакого npm install, только vendor, только node_modules, только хардкор. Связался с этим монстром только потому что он умеет почти все более-менее адекватные дистры.

Если нет возможности подбрасывать свои build dependencies, то нормального выхода нет. Но я думаю, что такой способ есть. Или инстанс OSC не под твоим контролем?

Или инстанс OSC не под твоим контролем?

смотря что ты имеешь ввиду под контролем. Если возможность поставить на chroot добра не из репа - нет, это можно только если заливать в как один из исходников (в случае несоответствия chroot'а оригиналу chroot пересоздается)

Deb 7/8 имеют в stable Go 1.3, в то время как пачка либ требует 1.4 минимум

А зачем go на сервере? Бинари же статически линкуются.

А зачем go на сервере? Бинари же статически линкуются

а сам бинарь как собрать? а то статика это хорошо, но там есть динамика на базовые либы. мало ли на что оно может зацепиться когда под 10 дистров разом собираешь

смотря что ты имеешь ввиду под контролем

Примерно это: https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Adding_multipl... (если там можно добавлять левые репозитории и если у тебя есть пакет компилятора Go для платформы, на которой происходит сборка).

ого. не знал. спасибо.

Мне в целом не лень скачать бинарную сборку Go 1.7 и засандалить ее

Всё уже украдено до нас: https://github.com/niemeyer/godeb

godeb

а если rpm? вся жопа в куче различных версий дистров

Кстати, да. Собрал и опакетил под что хочешь. Зачем актуальный Go на сервере?

Что мешает собрать в статику под древним дистром?

Если прога FOSS - то сорцов достаточно. Смысл от пакетов?

Бинарь собрать на машине, с которой деплоишь. Зачем лишние сложности?

В Centos 7 есть

golang.x86_64 1.6.3-1.el7_2.1 @updates

Не совсем понятно, за что оно может зацепиться, но в любом случае как наличие go на сервере тебе поможет?

Да не на сервере. В chroot для сборки

Примерно это: https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Adding_multipl... (если там можно добавлять левые репозитории и если у тебя есть пакет компилятора Go для платформы, на которой происходит сборка).

только что опробовал. нифига, левые репы добавлять нельзя :(

плюс перепроверил какие репы вообще есть - везде кроме сузи только stable, никаких updates/backports. короче облом.

только что опробовал. нифига, левые репы добавлять нельзя :(

Насколько я понимаю, это штатный способ: https://forums.opensuse.org/showthread.php/510222-Third-Party-Repository-for-...

Конечно, если он не работает, тогда способ из хедпоста - единственный.

способ-то штатный, но работает он в пределах OBS. Т.е. все эти репы должны быть в системе, потому и путь выглядит не как URL, а типа «a:b:c». так что совсем левые нельзя, к сожалению

Бинарь собрать на машине, с которой деплоишь. Зачем лишние сложности?

а если к машине с которой пойдет деплой доступа нет? деплой производит третья сторона, которой выписывается OTP на разовый доступ. не спрашивай зачем и почему, это не продакшн а ресерч.

Значит соберёшь бинарь на своей машине и отдашь на деплой.

Как в этом случае поступить адекватно?

Адекватно никак.

Как сейчас опакечивают golang библиотеки

Адекватно никак.

в итоге все-таки пришлось бандлить целый бинарный Go :( не, я не против чтоб он валялся на CI-сервере чтоб его в виртуалки пихать во время билда, но это очень жестко.

А что, поставлять в пакете только скомпилированный/слинкованный статично бинарник - какая-то проблема? Для этого же не нужно тянуть go runtime.

типа скомпилил у себя и с умным видом подсунул в osc сразу бинарь?

Я ж не в пакет хочу Go запихать, а на сервак который эти пакеты делает

Ну поставь на сервак последний go с офф сайта, вне пакетного менеджера, распакуй бинарник go компилятора в /opt/go и добавь в PATH.

Ну поставь на сервак последний go с офф сайта, вне пакетного менеджера, распакуй бинарник go компилятора в /opt/go и добавь в PATH

эх... я собираю через osc. это клиент к openSuse Build Service. Доступа к их серваку у меня разумеется нету кроме как клиентом. osc разворачивает чистый chroot из stable либо других репов из того же osc/obs. Закинуть туда бинарь можно только одним способом - забандлить его вместе с исходниками как еще один source-файл и дальше на свежеподнятой виртуалке скриптами распаковывать. В итоге так и делаю, но это, блин, тупо страшно с точки зрения адекватности