Установка и пакетирование

Про установку посмотрим в процессе пакетирования.

Основания свободной дистрибуции

Свободное лицензирование

Условия распространения исходного и модифицированного ПО

0. Право на использование
1. Право на изучение и модификацию (⇒ доступ к исходному тексту)
2. Право на распространение

3. Право на распространение модифицированных версий

Обратите внимание:

• Ничего не сказано про дисциплину изменений

• Ничего не сказано про деньги, однако запрет коммерческого использования — это прямое нарушение свободной лицензии

• Ничего не сказано про передачу исключительных прав (например, надо ли сохранять авторство? зависит от конкретной лицензии)

⇒ Ещё один пункт, т. н. Копилефт — сохранение свободности лицензии:

4. Лицензия, под которой распространяется производный продукт, должна соответствовать всем пяти пунктам исходной лицензии (⇒ доступ к исходному тексту)

Это основание для того, чтобы 24/7 составлять сборник модифицированного ПО.

Открытая разработка

Дисциплина разработки ПО, требующая участия сообщества

• Цель: разработка ПО

• Задача: привлечение и мотивация сообщества к разработке
  • Упрощённая процедура входа/выхода в сообщество (только профессиональная градация, да и то умеренно)
  • Информационно-техническое пространство (Wiki/списки рассылки/SN — Bugzilla/Сборочница)
  • Поощрение распространения и использования в личных целях ⇒ свободное лицензирование
  • Особая дисциплина разработки
    • DVCS
    • С упором на «личное удобство»
    • С упором на «удобство для сообщества»

Пакеты и дистрибутивы

«Дистрибутив ОС» — это

• Комплект пакетов (несколько тысяч)
  • Гарантия совместимости: участие в репозитории
  • (вполне возможно) Дополнительное тестирование/оформление
• Программа-установщик
• (вполне возможно) Решение каких-то коммерческих задач

Репозиторий

• Собственно, сборник (+доставка)
• Сборка на стороне репозитория (aka сборочница)
  • Изолированная в чистом окружении
  • Гарантия оформления в соответствии с дисциплиной
  • Дополнительные тесты при сборке
• Интеграционное тестирование
  • Например, наличия зависимостей (т. е. отсутствия unmet-ов)

  • Например, работа с полной таблицей символов, предоставляемых всем репозиторием

  • файловых конфликтов
  • …

Пакет

Целая лекция только про пакеты

• Комплект файлов (архив)
• Установка/удаление (регистрация/дерегистрация)
  • Специфика файлов: конфигурационные, призраки и т. п.
• Установочные сценарии
  • pre-/post-, -install/-config и пр.
  • триггеры — общесистемные сценарии
• Установочные зависимости (на другой пакет, на файл, на «сущность»)
• Конфликты и альтернативы
Установщик пакета
Работает с отдельными пакетами
• установка / удаление (deb: переконфигурация) / обновление
• отслеживание зависимостей
• проверка целостности
Пакетный диспетчер
Работает с репозиториями
• доставка
• построение и обсчёт дерева зависимостей
• рекурсивная установка / удаление / обновление
  • с учётом возможной разноверсицы
  • по вторичным provides
Сборщик пакетов
Работает со спецификацией

• Разворачивает исходники
• «Проигрывает» процедуру сборки:
  • Применяет патчи
  • Запускает сборку
  • Запускает установку в подкаталог
  • Формирует бинарный пакет
• Не требует root!

• Требует наличия сборочной среды

Сборка пакета

Пакет (быстренько):

• Исходный текст (апстрим)
• Патчи и собственные исходники
• Спецификация
  • Метаинформация (имя, версия, описания и т. п.)
  • Процедура сборки
  • Эксплуатационные зависимости (в т. ч. автоматически определяемые)
  • Сборочные зависимости (их надо установить!)

Всё это подаётся на вход сборщику (ALT: rpm-build).

Живая сборка обновления пакета:

В этом году на примере yad

1. Новый апстримный исходник
2. Исправление спека
3. Попытка сборки (с наложением патчей)
4. Исправление отвалившихся патчей
5. Исправление собственных исходников

   • например, перевода: make update-po ; msgfmt --statistics ru.po

6. Ещё исправление спека, если нужно (например, новые файлы)
7. …и так по кругу

Посмотреть автовычесленные зависимости.

Тестирование пакета.

Сопровождающий (майнтейнер) пакета

Человек из сообщества, который всё это делает, а ещё взаимодействует с апстримом (вешает баги и т. п.)

Помещение пакета в репозиторий (показать не успею):

1. Подпись и закачка на сборочницу исходного пакета (.src.rpm)

2. Сборочница
   0. собирает пакет в изолированном (в т. ч. без сети) окружении актуального репозитория
   1. Тестирует его на соответствие Policy
   2. Тестирует его на интеграцию в репозиторий (например, на requires/depends). В Сизифе недопустивы unmets (неудовлетворённые зависимости)
   3. Тестирует его на установку в чистое изолированное окружение
   4. Если всё хорошо, помещает пакет в репозиторий

⇒ Довольно много особенностей, например, группы взаимозависимых заданий и т. п., но об этом надо отдельно