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

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

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 по инструкции

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

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

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)

Д/З

• См. предыдущее домашнее задание. Доделать.

• В чем разница между apt-cache depends и rpmquery -R?

• Изучить структуру хранилища ALT Linux Sisyphus и соотнести его с содержимым /etc/apt/sources.list.d/alt.list

• Скачать простейший SRPM-пакет, собрать и установить его

• Перегененрировать сборочные зависимости этого пакета. Что-нибудь изменилось? В каком пакете лежит buildreq?

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

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

• Исторические корни
• Состав: исходники (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. «Разработчики»: выпуск — это отдельная ветка (возможно, со своими обязательствами по техподдержке)
       • Использование веток и тегов
       • Ветка лучше архива с выпуском: в ней можно исправлять ошибки

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

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

0. Выбор upstream
1. Адаптация исходников
2. Подготовка пакета
3. Тестирование пакета
4. Публикация и эксплуатация

5. (обноврение upstream) => см. п. 1

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

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

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

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

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

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

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

   • find-requires, find-provides, buildreq, brp

1. Изолированная сборка в сборочнице
   • воспроизводимый результат
   • автоматический контроль дисциплины оформления пакета
   • расчёт на установку бинарных пакетов
   • неудовлетворённые (unmets) зависимости и борьба с ними
     • авторассылка по сопровождающим
     • учёт изменения общего количества unmets
   • хранилище «всегда нестабильное»
2. Изолированная сборка с выделением сборочных подмножеств и контролем со стороны сопровождающего (на пример 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: new → add/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
  • обновление исходников
  • модификация спецфайлов
  • сборка обновлённой версии
  • контроль качества сборки