Я хочу провести небольшую, но содержательную экскурсию на тему «От идеи до готового пакета».
Всё начинается с идеи, с желания видеть определенную программу в SliTaz.
Сделаем шаг в сторону. Существует множество дистрибутивов, основанных на пакетной базе Debian. Эти дистрибутивы просто берут у них готовые пакеты, возможно, перепаковывают в свой формат, но это не наш путь. В SliTaz имеется лишь небольшое количество «позаимствованных» пакетов. Для получения этих пакетов разработаны скрипты, названия которых начинаются на «get-»: вот их полный список. Во всех остальных случаях пакеты для SliTaz компилируются из исходного кода и упаковываются в самом SliTaz. Это позволяет компилировать программы выбранным компилятором, с выбранными опциями (иногда можно запретить или разрешить какую-то особенность программы, что в конечном итоге повлияет на полезность и размер программы), с точно совпадающим к нашим условиям набором системных библиотек (программа, скомпилированная в более новой среде в «чужом» дистрибутиве, будет требовать новые библиотеки).
Возвращаемся из этого закоулка на наш путь. Программы (пакеты) компилируются из исходников. Это можно сделать вручную, но тут больше рутины, чем творчества, а также присутствует элемент случайности и непредсказуемости. Количество готовых пакетов в SliTaz медленно, но верно приближается к 4 тысячам (3899). Был разработан инструмент, убирающий рутину из процесса создания пакетов. Он настолько удобный, что я уже давно ничего не компилирую вручную. Текущая инкарнация этого инструмента называется Cookutils. Это «сборочный бот». Он получает на входе «рецепт» с четкими указаниями и выдает на выходе готовый пакет.
Вот как выглядит рецепт для GPartEd: pkgs.slitaz.org/search.sh?receipt=gparted&version=cooking
Формат рецепта совместим с форматом shell-скриптов. Здесь мы видим комментарии, начинающиеся со знака «#», определение всех необходимых переменных и функций. В функции бота входят: загрузить архив с исходниками, распаковать его, установить все пакеты, необходимые для компиляции и сборки данного пакета, запустить { конфигурирование исходников, их сборку и установку }(по правилам, предусмотренным разработчиками пакета) [с учетом параметров, которые нам необходимы, например, устанавливать программу не в /usr/local/bin, а в /usr/bin], собрать из скомпилированных файлов кусочек файловой системы и создать из него пакет, после этого «подчистить за собой», убрав пакеты, которые были установлены перед компиляцией этой программы, вернув сборочную систему в исходное состояние.
Рутина убрана, осталось творчество ;)
Обычно, рецепты написаны таким образом, что достаточно изменить в нём номер версии в переменной VERSION для того, чтобы можно было собрать пакет с новой версией (если разработчики данной программы не привнесли туда чего-то кардинально нового, т.е. в случае минорных изменений).
Теперь нужно рассказать, как управлять таким огромным количеством рецептов, ну, и самим ботом.
Для хранения рецептов применяется система контроля версий Mercurial (Hg, ртуть). Это очень удобно, все изменения записываются, их можно окинуть взглядом и проанализировать. Вот так, например, выглядит «биография», история рецепта пакета GPartEd (начало внизу): hg.slitaz.org/wok/log/tip/gparted/receipt
Оказывается, ему уже 5 лет! И он вырос с версии 0.3.3 до 0.14.1 за это время.
Кстати, система Mercurial консольная, она установлена на одном из серверов проекта SliTaz, а то, что мы видели сейчас — это ее веб-интерфейс. Это очень удобно, потому-что веб-браузеры сейчас есть сейчас не то, что в мобилках, но даже в некоторых холодильниках! ;)
Mercurial позволяет разработчикам совместно выполнять свою работу. Достаточно установить себе Mercurial и сделать локальную копию хранилища рецептов (называется wok), а потом периодически обновлять локальную копию, чтобы получить изменения сделанные другими, а также вносить свои изменения в копию, находящуюся на сервере, чтобы наши изменения могли увидеть другие.
Нужно отметить, что имеется три версии wok: набор рецептов для текущей стабильной версии SliTaz (wok-stable), для разрабатываемой следующей версии (wok) и экспериментальный (wok-undigest, где допустимы любые эксперименты с «отклонением от генеральной линии партии»).
Остался один, вполне логичный шаг от wok к сборочному боту. Посредством cron бот активируется и проверяет изменения во всех wok (для wok и wok-stable это происходит каждые 2 часа, а для wok-undigest — реже, каждые 4 часа). При отсутствии изменений бот опять «впадает в спячку», а при наличии — собирает новые пакеты.
Сборочный бот имеет свой веб-интерфейс: cook.slitaz.org.
Здесь можно увидеть его текущее состояние, какие пакеты собрались, а какие — нет, просмотреть журналы компиляции. После сборки пакетов, раз в сутки они отправляются с сервера бота на сервер Mirror, откуда они становятся доступными всем пользователям SliTaz. С сервера Mirror происходит «зеркалирование» и на другие сервера.
Это была история о том, какой путь проходит от идеи до пакета в вашем пакетном менеджере. Но «за кадром» всё же осталось много интересного.
Откуда берётся номенклатура пакетов? Ходим-бродим по интернету, ищем, чего бы еще собрать. Прислушиваемся к пожеланиям пользователей. Не всё удается собрать. Иногда не хватает нужных пакетов-зависимостей, иногда — опыта.
Тратится определенное время на написание рецепта и его отладку. Работа проводится с локальным, установленным на своей машине, сборочным ботом. После того, как пакет собрался и программа запустилась и работает так, как от нее ожидают, рецепт забрасывается в wok.
Почему мы не можем иметь в текущей стабильной версии SliTaz новые версии пакетов? Ведь в разрабатываемой версии давно уже имеются работающие новые версии и новые пакеты. Ключевое слово здесь: «стабильность». Инфраструктура пакетов имеет сложную взаимосвязь. Никогда не слышали присказку: «не было печали, апдейтов накачали»? У нас пока еще нет инструмента, позволяющего определенно сказать, будет ли всё работать, или (уже бывшая) система «рухнет» или «накроется медным тазом». Разве что, кто-нибудь напишет этот инструмент. Нет людей, готовых тестировать новые пакеты для текущей версии в связке с другими пакетами. Перед выпуском новой стабильной версии произойдут обычные и закономерные действия. Сначала все пакеты программ и их зависимости (и зависимости зависимостей), в общем, все будут пару раз (для верности) пересобраны сборочным ботом. При наличии ошибок, они будут устраняться. При отсутствии ошибок будет выпущен RC1 (Release Candidate No. 1) — кандидат на выпуск следующей версии SliTaz. После тестирования RC1 на различном оборудовании и в различных условиях всеми желающими пользователями SliTaz, будут исправляться ошибки и недочеты в работе RC1. Будет выпущен RC2, и так далее, пока команде разработчиков система не покажется достаточно пригодной и стабильной. И тогда, какой-нибудь RC3 и будет назван новой стабильной версией.
Как проверяются зависимости? Эта работа возлагается на конфигуратор, находящийся в пакете с исходниками. Он ищет всё необходимое для того, чтобы пакет мог быть собран. Если чего-то не хватает, то он «громко падает» и до компиляции дело не доходит.
Принимаются вопросы, пожелания, уточнения…
Статья была написана как ответ на тему форума SliTaz Как обновляются пакеты?
