Разработчики дистрибутива AlmaLinux, развивающего похожий на CentOS бесплатный клон Red Hat Enterprise Linux, представили новую сборочную систему ALBS (AlmaLinux Build System), которая уже использована при формировании выпусков AlmaLinux 8.6 и 9.0, подготовленных для архитектур x86_64, Aarch64, PowerPC ppc64le и s390x. Кроме сборки дистрибутива ALBS также используется для генерации и публикации корректирующих обновлений (errata), и заверения пакетов цифровой подписью. Код сборочной системы написан на языке Python и...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57384
Чем не угодил Open Build Service, имеющий возможность собирать для львиной доли дистров пакеты - не понятно.
А хотя, если "всё своё хотим" - тогда оправдано. Ну, тогда сделайте только для своего продукта - зачем копировать и так хорошо работающие рещшения?
>Чем не угодилЛень узнавать почему альмы так быстро рожают релизы, особенно 9ку. Но возможно их цапцарапалка самая быстрая )
Там не сборочка одного проектика.
Там многоитерационная сборка, которая посерёдке легко может фейлиться до следующего цикла.
При этом собранные пакеты подставляются в саму сборочную систему для следующего цикла сборки.
Что-то это как-то фу. Когда пакеты циклически зависят друг от друга, в итоге из-за одного битого пакета окажется битым другой совершенно никак к нему не относящийся. Я думаю, многие, кто игрался с флагами на генте, через это проходили. Сборка должна быть с нуля, чистой и воспроизводимой. А то слишком часты ситуации, когда что-то внезапно фейлится, и пойди нади там, из-за чего.
> из-за одного битого пакета окажется битым другой совершенно никак к нему не относящийсяЭто как?
>> из-за одного битого пакета окажется битым другой совершенно никак к нему не относящийся
> Это как?Бывает такое дело, в итоге часть пакетов работают с либой, а часть выдаёт самые разные ошибки, никогда не догадаешься. При этом, это какая-то зависимость зависимости использованного в коде проекта. Ещё очень часто у тебя что-то скомпилировалось нормально, ты пробуешь пересобрать всё дерево зависимостей этого пакета, и всё в итоге рассыпается, а этот пакет вообще больше не компилируется. Надо пересобрать вообще весь мир с отключением оптимизаций, и тогда, может быть, соберётся, или отвалится ещё что-нибудь и ты найдёшь, в чём причина. Хотя всё работало и никаких проблем не было. Поэтому полная пересборка всего при обновлении имеет некоторый смысл, чтобы такие вещи сразу обнаруживались.
За 3 года что Гента была локалхостом не наблюдал того о чем вы говорите
Это надо уметь. Для быстрого эффекта могу порекомендовать собрать мир с lto (no-fat-lto-objects тоже) и graphite. Скорее всего даже не соберётся половина, но с одним из прошлых релизов gcc соберётся. А ещё там libc или libz или libreadline сдохнут, удачи в экспериментах, в общем.
Собираю с lto (и с -fno-fat-lto-objects) со времён, когда требовалась создавать ссылку вида
/usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0 -> /usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/liblto_plugin.so.0.0.0zlib и readline собрана с lto, судя по отсутствию в списке исключений.
Бывали проблемы линковки с библиотеками, собранными с lto, это да (причины понятны - нужные клиентам символы "оптимизируются" из экспорта).
Что бы что-то не работало, пока единственная подтверждённая проблема: https://bugs.gentoo.org/802027#c10
Есть ещё какие-то?
Одного LTO мало, но и с ним каждое обновление компилятора новые приключения. Я отказался от общесистемного lto несколько лет назад. Слишком, слишком много возни. Если есть время и собралось сейчас, не значит, что будет собираться через неделю или месяц. Причём, отвалится тот пакет, с которым никогда таких проблем не было (стараниями разрабов). Какой-нибудь perl или awk, внезапно.Да вот кстати голдом тоже перестало всё собираться, даже ядро (разрабы отказались, у меня не было с ним проблем). Но это отдельная тема. Другой квест. Отказ от голда в конечном счёте не избавил от проблем и только добавил новых. Зависит ещё от разрабов, есть много странного или вовсе некорректного кода, который случайно работает (в основном легаси), а различные оптимизации обнаруживают эти проблемы.
Что помимо LTO надо? graphite включено. Может быть дело в том, что начал собирать давно и список исключений с тех пор не очень то и чистил. Или просто некоторые приключения (пересобрать зависимость) не запоминаю, поскольку решаются тривиально "на автомате".С ядром, да, похоже были проблемы:
# cat /etc/portage/patches/sys-kernel/linux-custom/force-ld-bfd.patch
--- linux/Makefile.orig 2019-06-08 15:00:00.333726512 +1000
+++ linux/Makefile 2019-06-08 15:00:02.933725595 +1000
@@ -393,7 +393,7 @@else
CC = $(CROSS_COMPILE)gcc
-LD = $(CROSS_COMPILE)ld
+LD = $(CROSS_COMPILE)ld.bfd
AR = $(CROSS_COMPILE)ar
NM = $(CROSS_COMPILE)nm
OBJCOPY = $(CROSS_COMPILE)objcopy
Теперь надо собрать мир с графитом и lto, ну там -floop-block -fgraphite-identity -floop-strip-mine -ftree-loop-linear -floop-interchange, Есть ещё -floop-nest-optimize например, он ломал openssl crypto/asn1 (если верить комментарию).Я сейчас использую system-wide: -fno-semantic-interposition -fno-plt -fipa-matrix-reorg -fipa-pta, были проблемы, но не сейчас. С no-semantic-interposition glibc после недавнего переезда на libxcrypt сдохла после установки, особенное удовольствие доставил факт того, что пакетный менеджер никак не может даунгрейднуть бинарный пакет glibc из кеша из-за изменившихся зависимостей и системная glibc просто поломана. И с no-plt, по-моему, что-то с вайном 32-битным было, ему надо включать отдельно. Любому пакету где lazy binding. Так -z,relro,-z,now, да.
Что с dev-libs/ncnn я так и не понял, собирается только с arch=core2, какие-то косяки с ассемблером емнип. Всё остальное сейчас в порядке.
> особенное удовольствие доставил факт того,
> что пакетный менеджер никак не может даунгрейднуть бинарный пакет glibc из
> кеша из-за изменившихся зависимостей и системная glibc просто поломана.А это вообще отдельная тема. Очередная победа идеологии над здравым смыслом. Зато место сэкономили. =) Если с apt-get решение возможно, но никто не озадачился, то с emerge и python-ом не очень понятно что делать.
Воспроизводимой она может стать только после того раза, как все пакеты собраны циклически первый раз.
Потому что на минуточку, у конкретно этой сборки НЕТ базовой системы, она бутстрапится сама в себя.
(но по факту после 1 итерации она ещё не воспроизводима, и воспроизводимость появляется после нескольких итераций)
Собственно, если этого не делать - пупсики не смогут пересобрать у себя пакетик, поправив один байт.Потому что у них альмалинукс, а не сборочная ферма специально под задачу собирания одного пакетика.
Ну, не. После того, как воспроизводимость достигнута, сборка ведёт себя как нормальная сборочная система, позволяя собирать и по 1 пакету. Проблема в том, что редхат при больших апдейтах так же циклически заново перебирает фигову тучу таковых.
То есть это не совсем такая вот разовая операция. Собрали циклически 8.0 - дальше апдейты собираются по полтора пакета. Появился в сырцах 8.1 - придётся опять циклически перебрать все зависимости, чтобы добиться воспроизводимости. И снова сидим, собирая по штучке+зависимости до 8.2. 8.3. 8.4. x.y.
Ну да, говорю же - оно иначе не пересоберется на обычной системе, а традиционные дистрибутивы все еще старательно блюдут этот завет (давно уже, в общем-то, потерявший смысл - ну кто сегодня что-то еще пересобирает, это не девляпоугодно).
(если пытаться собирать на обычной не поставив все апдейты всего - то тоже может не собраться, из-за stable nonsense)
Если чуть попроще - сборка и есть сборочная система :D Поэтому "классика" тут не заходит однозначно.
Тем, что этот монстр абсолютно unmantainable. Найти в чём проблема там не представляется возможным, если что-то там случится. Там практически отсутствуют дебаг-логи, куча компонентов там — портянки на баше вызывающие перл, а затем снова ныряющие в портянки на баше. А если дебаг логи там и есть, то их информативность оставляет желать сильно лучшего. Починить в случае сбоя это всё очень сложно. Плюс, компоненты имеют привычку вставать там колом на ровном месте. И ты понимаешь, что что-то встало только тогда, у тебя, например, перестаёт сборка публиковаться, например. Или воркеры почему-то молчат. Но в логах при этом полнейшая тишина. Догадаться что отвалилось — только наугад.
И всё это очень плохочитаемое внутри. И что самое поганое, в реальности он нормально работает только на openSUSE. Поставить его на другой дистрибутив ОЧЕНЬ нетривиальная задача. Плюс, если нужно сборочный контейнер кастомизировать (например, добавить для сборки пакетов какие-то опции, то ты охренеешь искать, где это на самом деле вызывается).Я перечислил далеко не полный список проблем с этой штукой. В общем, любви к этой штуковине не понимаю абсолютно.
Это из собственный велосипед, который они катят с 2012 года. Понятно, что им проще сидеть на нем и дальше.
> предоставляются средства для автоматизации замены брендовОтличная сборочная система для создания исключительно своих, оригинальных пакетов
Так а чем koji не устроил, зачем нужно было переизобретать?
Вот я тоже не понял. Вроде всегдв им собирали.
всем страдать, что тут сказатьего (дистр) где то кроме одного из "местных" клауд провайдеров используют?
На его основе собирается Docker-контейнер manylinux для сборки нативных python wheels: https://github.com/pypa/manylinux
Свои инструменты создают не ради самих инструментов, а что бы вырастить команду специалистов, способных адаптировать инструменты под задачи и решать возникающие проблемы. В том числе и в будущем. Кто это не понимает, тот аутсорсит "полностью автономную" Automatic Build Farm, кидает субподрядчиков, а потом джва года смотрит на ошибку 500 сервера и ничего не может с ней поделать.
Ноль документации. Для кого представили не понятно.
Это та самая система что не может корректно запаковать rpm ?https://almalinux.discourse.group/t/alma-linux-9-error-insta...
Битый диск, проблемы с памятью как вариант. Тем более человек ниже написал, что установил данный пакет без ошибок.