Хранилища и дистрибутивы
Обновление пакета:
- Изменения 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) ? наполняется тем, кто выпускает дистрибутив(ы) ? сообществом или компаниями ? путем ветвления хранилища
- Обновление ошибочных и/или устаревших пакетов управляется выпускающим с некоторым дополнительным тестированием
- Может содержать гвозди, которыми прибиваются требуемые свойства дистрибутивов
- Дистрибутив ? подмножество ветки, включенное в распространяемый носитель или образ для установки ОС, изготовляется выпускающим
Существенно меньше ветки
- Тестирование пакетов, входящих в дистрибутивы
- Соответствующая ветка подключается в установленной ОС в качестве хранилища
Недостаток: распараллеливание работы по нескольким веткам.