Golang, это не только молодой и перспективный язык. Он еще и предлагает совершенно старые новые подходы к разработке и развертыванию - большие статически собранные исполняемые файлы. Все модули в момент сборки компилируются и включаются прямо в получаемый исполняемый файл. Это привело нас к интересному вопросу - а как быть с bundled libs?

Строго говоря, библиотек там нет. Вместо этого используется термин "пакет". В терминологии Golang, это кучка исходников, которые не загружаются во время работы, а подключаются при сборке. Получается, что он и попадает под определение "bundled lib"? Не так быстро!

Мы растаскиваем приложения на библиотеки перед сборкой, чтоб в будущем обновив одну из них, мы не обязательно были бы вынуждены обновлять все зависящие от нее приложения и библиотеки. А тут то так не получится! Пересобирать Go-приложение все равно придется. Да, теоретически, выделяя Go-пакеты в отдельные RPM-пакеты, можно упростить исправление ошибки - исправил один Golang-пакет и пересобрал его в RPM-пакет, и начинай пересобирать все зависящие от него RPM-пакеты. На деле это не даст значительного ускорения, зато увеличит работу по unbundling. Осознав это, мы решили пойти на компромиссный вариант - пока прекратить требовать выделения всех пакетов Go в отдельные RPM-пакеты, но если такие RPM-пакеты уже есть, то использовать при сборке именно их. Мы попросили Fedora Packaging Committee одобрить это решение, и в целом народ понял проблему, но предложили нам вместо решения лишь этого вопроса заняться более общей задачей - написать Golang Packaging Guidelines, где отразить эту особенность. Участники Golang SIG так и порешили.

Одно уже понятно - бездумный перенос работавших в других местах подходов не всегда продуктивен.