Хранилища и дистрибутивы

Обновление пакета:

  1. Изменения upstream (см. предыдущую лекцию)
  2. Изменения в хранилище и их последствия
    • обновление библиотек
    • обновление toolchain
    • изменение пакетного состава

Историческое развитие хранилищ

  1. Локальная сборка + каталогизация на сайте
    • индивидуальная дисциплина сборки
    • (рас)синхронизация сборочных окружений
    • расчёт как на установку пакета, так и на «установку из исходников»
    • find-requires, find-provides, buildreq, brp

  2. Изолированная сборка в сборочнице
    • воспроизводимый результат
    • автоматический контроль дисциплины оформления пакета
    • расчёт на установку бинарных пакетов
    • неудовлетворённые (unmets) зависимости и борьба с ними
      • авторассылка по сопровождающим
      • учёт изменения общего количества unmets
    • хранилище «всегда нестабильное»
  3. Изолированная сборка с выделением сборочных подмножеств и контролем со стороны сопровождающего (на пример Sisyphus)
    • контроль качества всего хранилища по результатам сборки (unmets, использование несуществующих символов в библиотеках) и запрет сборок, снижающих качество
    • => необходимость групповых сборок (замкнутых по изменению зависимостей)

    • => гибкие права на сборку пакета

    • => проверка наследования новых пактов старым (за счёт использования DVCS)

    • => управление процессом сборки со стороны сопровождающих

    • возможность тестовой сборки (без добавления в хранилище)
    • публикация (даже неуспешных) результатов сборки в виде мини-хранилища для тестирования

Есть также история развития локальной сборки: FreeBSD, Gentoo.

Варианты ЖЦ хранилищ

Эшелонированный

Пример — «дистрибутивы» GNU/Debian):

  1. Нестабильный (unstable) — наполняется сообществом
  2. Тестируемый (testing) — наполняется роботами путём добавления групп пакетов, которые
    • не имеют критических ошибок
    • не ломают зависимостей
    • не ломают установки и удаления
  3. Стабильный (stable) — изготовляется сообществом путём заморозки и зачистки testing
    • Принимаются только пакеты с устранением критических ошибок
    • После выпуска testing размораживается

Недостаток: непредсказуемое время выпуска stable

Древовидный

На примере ALT (похожая схема в FC, Ubuntu, SuSE, …)

  1. Хранилище (Sisyphus) — наполняется сообществом

    • Автоматическое недопущение unmet (за счёт групповой сборки)
    • Непредсказуемый уровень тестирования
  2. Ветка (или «платформа» p5, t5, p6, t6, p7) — наполняется тем, кто выпускает дистрибутив(ы) — сообществом или компаниями — путём ветвления хранилища

    • Обновление ошибочных и/или устаревших пакетов управляется выпускающим с некоторым дополнительным тестированием
    • Может содержать гвозди, которыми прибиваются требуемые свойства дистрибутивов
  3. Дистрибутив — подмножество ветки, включенное в распространяемый носитель или образ для установки ОС, изготовляется выпускающим
    • Существенно меньше ветки

    • Тестирование пакетов, входящих в дистрибутивы
    • Соответствующая ветка подключается в установленной ОС в качестве хранилища

Недостаток: распараллеливание работы по нескольким веткам.

LecturesCMC/PackageMaintaining2013/06-Repositories (last edited 2013-04-25 13:50:03 by FrBrGeorge)