Хранилища и дистрибутивы
Обновление пакета:
- Изменения upstream (см. предыдущую лекцию)
- Изменения в хранилище и их последствия
- обновление библиотек
- обновление toolchain
- изменение пакетного состава
Историческое развитие хранилищ
- Локальная сборка + каталогизация на сайте
- индивидуальная дисциплина сборки
- (рас)синхронизация сборочных окружений
- расчёт как на установку пакета, так и на «установку из исходников»
find-requires, find-provides, buildreq, brp
- Изолированная сборка в сборочнице
- воспроизводимый результат
- автоматический контроль дисциплины оформления пакета
- расчёт на установку бинарных пакетов
- неудовлетворённые (unmets) зависимости и борьба с ними
- авторассылка по сопровождающим
- учёт изменения общего количества unmets
- хранилище «всегда нестабильное»
- Изолированная сборка с выделением сборочных подмножеств и контролем со стороны сопровождающего (на пример Sisyphus)
- контроль качества всего хранилища по результатам сборки (unmets, использование несуществующих символов в библиотеках) и запрет сборок, снижающих качество
=> необходимость групповых сборок (замкнутых по изменению зависимостей)
=> гибкие права на сборку пакета
=> проверка наследования новых пактов старым (за счёт использования DVCS)
=> управление процессом сборки со стороны сопровождающих
- возможность тестовой сборки (без добавления в хранилище)
- публикация (даже неуспешных) результатов сборки в виде мини-хранилища для тестирования
Есть также история развития локальной сборки: FreeBSD, Gentoo.
Варианты ЖЦ хранилищ
Эшелонированный
Пример — «дистрибутивы» GNU/Debian):
- Нестабильный (unstable) — наполняется сообществом
- Тестируемый (testing) — наполняется роботами путём добавления групп пакетов, которые
- не имеют критических ошибок
- не ломают зависимостей
- не ломают установки и удаления
- Стабильный (stable) — изготовляется сообществом путём заморозки и зачистки testing
- Принимаются только пакеты с устранением критических ошибок
- После выпуска testing размораживается
Недостаток: непредсказуемое время выпуска stable
Древовидный
На примере ALT (похожая схема в FC, Ubuntu, SuSE, …)
Хранилище (Sisyphus) — наполняется сообществом
- Автоматическое недопущение unmet (за счёт групповой сборки)
- Непредсказуемый уровень тестирования
Ветка (или «платформа» p5, t5, p6, t6, p7) — наполняется тем, кто выпускает дистрибутив(ы) — сообществом или компаниями — путём ветвления хранилища
- Обновление ошибочных и/или устаревших пакетов управляется выпускающим с некоторым дополнительным тестированием
- Может содержать гвозди, которыми прибиваются требуемые свойства дистрибутивов
- Дистрибутив — подмножество ветки, включенное в распространяемый носитель или образ для установки ОС, изготовляется выпускающим
Существенно меньше ветки
- Тестирование пакетов, входящих в дистрибутивы
- Соответствующая ветка подключается в установленной ОС в качестве хранилища
Недостаток: распараллеливание работы по нескольким веткам.