Количество бинарных пакетов в репозитории Calculate Linux превысило 5000 шт.
Поддержание бинарного репозитория решает сразу несколько задач:
- Снижение процессорных издержек на компиляцию. Критично на слабых машинах на которых собирать тяжелые пакеты приходится длительное время.
- Снижение дисковых требований на установку обновлений. Критично при обновлении систем загруженных с Live USB.
- Скорость установки обновлений. Важно на нагруженных серверах, когда во время обновления могут некорректно работать службы. Именно поэтому по умолчанию Calculate Linux использует параллельный режим установки пакетов.
- Разрешение зависимостей. При каждом обновлении бинарных пакетов приводится в соответствие флаги и маски, максимально упрощая установку обновления пользователям.
Обновление репозитория не происходит в автоматическом режиме, как это может показаться на первый взгляд. Часть пакетов размаскирована, часть использует преднастроенные USE флаги. Всё это нужно отслеживать чтобы в один прекрасный момент нестабильное обновление не откатило например версию Firefox с 50.0.1 до 45.5.0 или не привело к блокировке обновления.
Первые бинарные пакеты стали собираться после перевода дистрибутивов на непрерывный цикл обновления. Стали формироваться регулярные ночные сборки и вестись репозитории бинарных пакетов каждого дистрибутива. Пакеты учитывали особенности флагов и масок каждой сборки но включали только те пакеты, которые входили в образы. Чтобы решить эту проблему, был проведён анализ USE-флагов и сформированы два профиля - десктопный и серверный. Бинарные репозитории были объединены в три: десктопный, серверный и общий. С появлением в портежах поддержки единого репозитория, в котором несколько версий пакета собранных с разными USE-флагами разделяются суффиксом, Calculate Linux был переведён на использование единого репозитория. В таком репозитории прекрасно уживаются две версии пакетов собранные для десктопа и для сервера.
Были определённые сложности связанные с временем обновления портежей и репозиториев. Не смотря на то, что дистрибутив распространялся на десятке зеркал, использовать под репозитории бинарных пакетов можно было только одно-два зеркала - те, которые предоставляли доступ для загрузки обновлений внешним источникам. К счастью, эта проблема впоследствии была решена. В файле ini.env, расположенном в директории /grp зеркала стали вестись версии коммитов оверлеев calculate, distros и portage на момент обновления пакетов. Утилита обновления cl-update стала считывать этот файл с зеркала и обновлять портежи и оверлеи до заданных коммитов. Таким образом, системы получают обновления во многих случаях исключающие блокировки пакетов и имеющие в стабильных версиях пакетов бинарные обновления. Версионность позволила добавить дополнительный контроль при подготовке обновлений. Промежуточные зеркала при распространении обновлений играли роль тестовых зеркал. Так же была явно выделена ветка промежуточных обновлений.
Сборка дистрибутивов Calculate Linux так же была переведена на бинарные пакеты. Это позволило высвободить время на тестирование обновлений и, как результат, увеличить количество поддерживаемых сборок. Новый подход позволяет своевременно выпускать обновления ядер. Более того, сейчас, при желании вы можете размаскировать и установить самое свежее ядро из бинарного пакета.
Конечно есть и свои сложности в поддержке репозитория бинарных пакетов. Приходится тратить время на разрешение зависимостей пакетов, которые не входят ни в один дистрибутив. Некоторые пакеты собираются с «магическими зависимостями», когда пакет на этапе сборки связывается с библиотеками в системе, отсутствующими в зависимостях у ebuild-а. На просчёт зависимостей и сборку пакетов тратится больше времени и повышает требования к железу.
В следующем году мы постараемся взять новый рубеж, охватив большую часть как минимум стабильных пакетов портежей. Для этого понадобится переосмыслить некоторые вещи в подходе к поддержке пакетов, добавить в шаблоны новые функции.