Сводный план курса «Сопровождение пакетов GNU/Linux»

Пакет: инструмент, ПО, предмет

Как и зачем становятся сопровождающими?

  1. Пакет как инструмент и компонент ОС: устновка, настройка, удаление, обновление
    • Пользователь
  2. Пакет как удобный способ оформления ПО: сборка по спецификации, полуавтоматическая проверка, тиражирование
    • Разработчик/сборщик
  3. Пакет как элемент ЖЦ хранилища и дистрибутива
    • Сопровождающий

Д/З

Установить (например, в виртуальную машину VirtualBox) дистрибутив Альт Линукс 6.0 Кентавр. Во время установки выбрать пункт «средства разработки». Ставить десктопную или серверную версию — решайте сами: на сервере почти нет Xorg (можно запустить startx и получить fvwm+firefox), на десктопе — Gnome2

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

Установка ПО

Достоинства и недостатки:

  1. Прямая сборка: Крибле! Крабле! Бумс! aka configure-make install
  2. Сборка по рецепту
    1. Сборка по рецепту из хранилища, source-based дистрибутивы
  3. Установка заранее собранного бинарного пакета
  4. Установка бинарного пакета из хранилища

Виды пакетирования

Главный вопрос: влияют ли пакеты друг на друга, и если да, то кто и как разрешает конфликты

  1. Пакет-дистрибутив (влияют, совместимость частично нивелируется базовой средой, частично остаётся на совести разработчика пакета)
  2. Пакет-изолированное окружение (не влияют)
  3. Пакет-пакет (влияют, совместимость проверяется при формировании хранилища)

Хранилища

  • Разделение на установщик и диспетчер
  • Достоинства общего хранилища
  • ПРоблемы множественных хранилищ

Использование apt и rpm в ALT Linux

Д/З

  • Установить в Альт Линукс 6.0 Кентавр пакет, затем удалить его

    • С помощью apt

    • С помощью rpm (предварительно скачав)

    • какими командами это делается?
  • Какие хранилища по умолчанию подключены?
  • Обновить систему
    • Ядро обновляется командой upadte-kernel

  • Попробовать установить GoogleTalk plugin по инструкции

Пакет в системе

Установщики и диспетчеры в разных дистрибутивах:

Установщик

Диспетчер

Red Hat/FC

rpm4

yum

Mandriva

rpm5

urpmi :(

SuSE

rpm4

zypper

GNU/Debian

dpkg

apt

ALT Linux

rpm4 {o} {o}

apt {o}

APT

  • Работа с хранилищами (apt-get) + работа с кешами (apt-cache)

    • параметры --fix-broken, --fix-missing, …

  • Основные команды: install, remove, update, dist-upgrade, search, show
  • Прочие команды и зачем они нужны
  • Формат файла sources.list (sources.list.d/*), подписи, методы доставки

  • Работа с репозиториями. apt-repo

RPM

  • Установка/удаление/обновление, проверка, сборка
  • rpminstall: [-i], -e, -U/-F (--old-package)

  • rpmquery: -i, -l, --scripts/--triggers, -R

  • rpmverify

Общий ключ -p

RPM: сборка из .srpm

  • rpm -i для .srpm, структура каталоге ~/RPM: BUILD, RPMS, SOURCES, SPECS, SRPMS

  • Сборочные зависимости
  • Сборка готового пакета без прав root, понятие buildroot

  • rpm -ba

    • Черновой подход к spec-файлу
    • .rpmmacros

    • Автопоиск зависимостей (find-requires/find-provides) и buildreq

    • Проверка rpm-а на выходе (build root policies)

Д/З

Сборка пакета из исходников

«Пакет исходников»

  • Исторические корни
  • Состав: исходники (upstream+patches+дополнительно) + спецификация
  • Пререквизиты: BuildReq и BuildPreReq

  • rpmbuild

  • Результат rpm -i *.src.rpm. Структура %_topdir
  • rpm --eval, rpm --showrc и rpm -bE RPM/SPECS/что-то.spec

Спецификация

Материал для изучения: http://www.altlinux.org/Spec На примере ALT RPM:

Структура spec-файла

Разделы, параграфы и макросы.

  • Много макросов в /usr/lib/rpm/macros*

  • ~/.rpmmacros

Разделы и полезные макросы:

  • Заголовок
    • Паспорт: Name, License, Summary, Group, Url
    • Версия: Version, Release, Epoch
    • Исходники: параграфы Source, Source#, Patch, Patch#
    • Зависимости: Build(Pre)Req, (Pre)Requires. Версии в зависимостях
    • Прочее: BuildArch, Provides, Obsoletes, Conflicts, …

    • макросы %name, %version, …, %summary
  • %description
  • %prep: %setup, %patch*
  • %build: %configure, %make, %make_build
    • Привязка к установке в каталог %buildroot
    • Макросы для других сборочных инструментов: %cmake, %autoreconf
  • %install
    • %makeinstall
    • %_что-то-там-dir, %_prefix
    • %find_lang (/usr/lib/rpm/find-lang)

  • %check
  • %files: %dir, %config, %attr
  • %changelog ([[http://www.altlinux.org/Руководство_по_написанию_changelog|ALT руководство)

    • автозакрытие ошибок
  • Множественные пакеты (%package и соотв. разделы)

Полезное при сборке

  • Редкоиспользуемые в ALT секции
    • %clean (никогда), %pre*/%post* (если триггеры не справляются)
  • rpmbuild … --short-circuit …
  • buildreq
  • findreq/findprov
    • понятие set-version
  • brp
  • Установка пакетов из свалки: rpm-dir в /etc/apt/sources.list

Ещё всякое

DPKG

  • Паспорт: *.dsc

  • Исходники (перепакованные): *.orig.tar.gz

  • Всё остальное: *.diff.gz (в виде патча, в т. ч. на /dev/null) или *.debian.tar.gz

    • Каталог debian:

      • ещё один паспорт: debian/control

      • Makefile сборки/устаноовки: debian/rules (+множество заготовок debhelper)

      • post/pre сценарии, меню, список файлов,
      • Всякое: changelog, license, список файлов разных типов (manpages, документация и т. п.)…
      • quilt и другие дисциплины пакетирования

      • debuild

Как оно бывает

Сборка пакетов в Debian. Изолированная сборка

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

Базовый документ: Debian Packaging Tutorial (Lucas Nussbaum, version 0.8 – 2013-03-03).

Пакет: ar-архив с файлами debian-binary, control.tar.gz, data.tar.gz

Сборка пакета: исходный архив, .dsc-файл, debian-архив (3.0+) или patch (старше)

Команды apt-get build-dep, apt-get source и debcheckout; пакеты build-essential и devscripts.

Содержимое каталога debian: control, rules, patches/, watch, собственные сценарии, прочее. Устройство файла rules.

Работа с птчами и сериями патчей. Quilt. Вспомогательные сборочные подсистемы: debhelper, CDBS, dh (aka Debhelper 7)

Сборка: debuild/dpkg-buildpackage и pbuilder.

Изолированная сборка

Недостатки развёртывания сборочного окружения в базовой системе.

Требования к изолированной сборке:

  • Сборочное окружение может формироваться на основе произвольного хранилища, не связанного с хранилищем, на которое настроена базовая система
  • Нельзя модифицировать базовую систему при (пере)развёртывании сборочного окружения
    • => chroot

    • => Запрет запуска команд с правами root

      • => fakeroot

  • Последующая сборка не должна зависеть от результатов предыдущей
    • => переразвёртывание сборочного окружения для каждой сборки

  • Нельзя модифицировать пользовательское окружение базовой системы
    • => запуск сборки с правами выделенного пользователя

ALT Linux hasher

Базовая ссылка: Wiki ALT Linux Team (в частности, статья Дмитрия Левина «hasher: технология безопасной сборки дистрибутива»)

Свойства: chroot, выделенные пользователи класса builder и rooter, кеширование неизменяемой части окружения.

Достоинства: максимально упрощённое использование при надёжной изоляции.

Специальные возможности: проброс/отключение сети, X11, каталогов /proc, /dev/pts и т. п.; формирование хранилища, пригодного к установке.

Команды hsh, hsh-rebuild, hsh-shell и hsh-run, hsh-install

Тонкости: заведение персональных выделенных пользователей с помощью hasher-useradd, использование tmpfs, удаление каталога со сборочным окружением (hsh --cleanup-only), (не)использование собственного хранилищя только что собранных пакетов (--without-staff), необходимость в локальной копии хранилищ (sisy[hus-mirror).

Работа с (плохо- или несобирающимися) .src.rpm непосредственно в hsh-shell. hsh --lazy-cleanup

Сизифов труд без помощи Сизифа

Переходная тема к собственно сопровождению пакетов.

Из мифологии совместной разработки

  • Эра «TAR». Обмен исходниками на магнитных лентах. Несмотря на свободной распространение, процесс разработки и информационное пространство вынужденно закрыты (по техническим причинам).

    • => Редкие выпуски по графику встреч

    • Тщательная подготовка выпусков и информационного пространства вокруг

    Эра «FTP». Интернет и рост информационной связности. Использование открытого и.п.: архивы исходников на FTP, странички на WWW.

    • => Выпуски по мере готовности

    • Использование обратной связи в разработке (почта, патчи и т. п.)

    Эра «GIT». Разработка и создание команды при помощи сети (DVCS, сервисы типа GH, SF)

    • => Использование DVCS для совместной разработки

    • Размытие понятия «выпуск»:
      1. «Хакеры»: каждая публикация — это выпуск, программа с каждым коммитом становится всё лучше
        • Основания: дисциплина коммитов, автосборка, компонентное и автоматическое тестирование
        • Недостаток: невозможность выбора стабильной версии
      2. «Разработчики»: выпуск — это отдельная ветка (возможно, со своими обязательствами по техподдержке)
        • Использование веток и тегов
        • Ветка лучше архива с выпуском: в ней можно исправлять ошибки

Цикл сопровождения пакета

Сизифов труд:

  1. Выбор upstream
  2. Адаптация исходников
  3. Подготовка пакета
  4. Тестирование пакета
  5. Публикация и эксплуатация
  6. (обноврение upstream) => см. п. 1 :(

Что нужно проверять:

  • Upstream:
    • Не переехал ли
    • Не сменил ли формать публикации
  • Сборку:
    • Патчи и их смысл
    • Дополнительные и пропавшие файлы
    • Установкe
  • Соответствие дисциплине оформления пакета
  • Работоспособность:
    • Надёжность
    • Функциональность
    • Перевод

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

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

  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. Дистрибутив — подмножество ветки, включенное в распространяемый носитель или образ для установки ОС, изготовляется выпускающим
    • Существенно меньше ветки

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

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

Управляемая сборочница

Особенности управляемой сборочницы:

  • групповая сборка → ACL (права доступа) на сборку
  • контроль:
    • целостности хранилища (по зависимостям и по символам в ELF)
    • установки
    • собираемости (возможно рекурсивной)
  • параллельная сборка
  • контроль наследования → DVCS
  • результат сборки (даже неуспешной) — мини-хранилище

DVCS для сборки пакетов

Git: (из прошлого семестра):

  • объект, его идентификация
  • рабочая копия
  • дерево
  • коммит
  • история
  • ветка
  • тег
  • слияние веток
  • публикация локального репозитория

Переписывание истории vs. сборка из репозитория

Git.alt: хостинг и сборка пакетов

Главная ссылка: http://git.altlinux.org/

  • Интерфейс: ssh
  • Работа с репозиториями:
    • packages/, public/ и private/

    • создание/удаление/переименование, клонирование
    • минимальная настройка git
    • find-package
  • Сборка:
    • выбор целевого хранилища
    • простая сборка: build

    • задания: task: newadd/delsub → … → run

  • ACL: acl … и task approve (ACL)

  • /gears/ и /srpms/ (http://git.altlinux.org/gears/ и http://git.altlinux.org/srpms/)

  • журнализация результатов (см. http://git.altlinux.org)

Gear: хранение исходников пакетов в git

Основная ссылка: Gear

  • Назначение Gear
  • Файл .gear/rules (см. примеры по ссылке выше): назначение и основные возможности

  • Форматы gear-репозитория
    • Линейный: patch-схема
    • С веткой upstream:
      • +ветка с модификациями
      • +ветка на каждый patch
    • Синхронизованный по VCS

Особенности сопровождения пакета по схеме «ветка upstream» + «ветка с изменениями» Особенности формирования хранилища при непосредственном импорте исходников из upstream VCS

Примечание: на лекции я обещал «сделать страничку с примерами использования git.alt». Это оказалось не нужно, вот эта страничка :)

Социальная роль сопровождающего пакет

  • Как стать сопровождающим?
    • Зачем?
    • Процедура приёмки на примере ALT
  • Ответственность за пакет = самодисциплина и дополнительная мотивация
    • …но не «обязанность»
    • ACL в Sisyphus: пакеты с запретом NMU, включение список группы @qa и @everybody

  • Задачи сопровождающего:
    • Сборка и тестирование
    • Отслеживание ошибок (issues). Системы отслеживания ошибок и их свойства.
    • Активность на информационных ресурсах (списки рассылки, форумы). Правила поведения в списке рассылки.

Разделение на «сборщиков» и «тестировщиков»

  • Профессионализация (=> сокращение роста) сообщества разработчиков СПО

  • Рост числа пакетов и сложности кода
  • => большое число пакетов у одного сопровождающего

    • => требование эффективного сопровождения

  • => невозможность совмещать глубокие знания в предметной области и навыки сборки сложных пакетов

    • => требование качественного тестирования

Задача: организация тестовых окружений для специалистов в предметной области (тестовые сборки git.alt? форумы? готовые виртуальные окружения?)

=> Роботизация (пере)сборки

  • Debian uscan/watch и его аналоги
  • Пакеты с готовыми данными (робот-сопровождающий)
  • Производные пакеты из других дистрибутивов (ALT autoimports)
  • Полуавтоматическое обновление на основе uscan
    • обновление исходников
    • модификация спецфайлов
    • сборка обновлённой версии
    • контроль качества сборки

LecturesCMC/PackageMaintaining2013/CoursePlan (last edited 2013-05-06 15:37:46 by FrBrGeorge)