Материал из eSyr's wiki.

• Презентация: PDF, ODP
• Аудиозапись: http://esyr.org/lections/audio/uneex_2009_winter/uneex_09_11_11.ogg, http://esyr.org/lections/audio/uneex_2009_winter/uneex_09_11_11.manmachine.ogg

До этого процесс сопровождения был рассмотрен для rpm-based дистрибутива alt linux, и хорошо бы рассмотреть, как он устроен в других дистрибутивах, в частности, Дебиан.

Сначала лектор хотел бы рассказать, что такое дебиан, поскольку тут есть ряд важных социальных, этических вопросов.

Вообще, дебиан --- это не дистрибутив. Зародился он как один из первых дистрибутивов линукс в 92-93 году, но вокруг него появилось комьюнити. Дебиан декларировал ряд правильных технологических идей, плюс ряд социальных явлений вокруг дистрибутива, его цели, собрало вокруг себя умных людей, которые предложили умные решения в технологическом плане.

В плане проекта создания ОС, есть документ, который декларирует цели проекта, debian social contract.

• Дебиан декларируется 100%-свободным. Причём, под свободой не стали вводить какие-то жёсткие критерии. Поступили проще, были более интуитивные постулаты. Это не столько определение, но метод, как определить, что ПО --- свободное:
  • Свободное распространение
  • Доступность исходного кода
  • Возможность производных работ
  • Не было дискриминации каких-то групп людей
  • Лицензия не должна требовать доп. вещей от человека, который получил этот софт
• Всё, что разработано в рамках проекта, будет возвращено в свободное сообщество
• Не прячутся никакие проблемы, все списки рассылки открыты (за исключением полутора специальных рассылок для обсуждения личных вопросов)
• Приоритеты проекта -- пользователи и СПО. Проект дебиан спокойно относится к проприетарному ПО. Кроме того, проект дебиан предоставляет свои ресурсы для свободных, проприетарных программ. Для несвободных программ есть специальное место, которое не включается печатаемые диски, но можно использовать также просто, как и

Что такое дебиан сегодня:

• 13 официально поддерживаемых архитектур (в том числе kFreeBSD)
• около 1000 разработчиков
• самый большой репозиторий
• Больше полумиллиона записей в багтреккере

Что удивительно, дистрибутив разрабатывается сообществом.

Три термина:

• Есть некое ядро, разработчики ОС --- Debian Developer. Стать таковым непросто, но вполне возможно. Таких немного, примерно 1000 человек, внутри есть иерархия. В частности, эти люди занимаются тем, что поддерживают ПО в рамках проекта.
• При этом, не обязательно быть девелопером, чтобы поддерживать пакет. Pacakge menteiner необязательно
• Debian maintainer --- он не является девелопером, но ему дано немножко больше прав, чем обычным людям, в частности, он может аплоадить пакеты.

[править] Роль "сопровождающего"

• Создание пакета
• Поддержка пакета: исправление ошибок и обновление пакета
• реакция на сообщения об ошибках
• Взаимодействие с апстримом
• NMU: в случае, когда человек собрал пакет и забыл, или в случае нахождения критической уязвимости, для таких случаев есть non-maintainer upload

Итак, как всё это организовано: взаимодействие между людьми осуществляется в списках рассылки. Списки рассылки открытые, туда необязательно подписываться, чтобы написать.

Кроме этого, используется bug tracking system для сообщений об ошибках в пакетах, о заявках на новые пакеты или о снятии с себя ментейнерства.

Есть ещё packet managing system для просмотра информации о пакетах. Можно подписаться на информацию о пакетах, об обновлениях.

Есть ещё alioth --- сервер, на котором поднят groupware, там куча списков рассылки, посвящённый конкретным продуктам (например, поддержке gnome в дебиане), там находятся различные системы контроля версий, и так далее.

Ещё есть вики, но она не очень активно используется, хотя некоторые вещи есть только там, например дополнения к debian policy.

Сам репозиторий дебиан, огромное хранилище, где хранятся пакеты и инструменты для управления ими.

BTS такой олдскульный, не смотря на то, что у него есть веб-интерфейс, основной способ взаимодействия --- через почту.

Есть ещё утилита reportbug, которой можно в качестве параметра передать имя пакета/бинарника, и она составит багрепорт.

Переходя к пакетам. То, о чём уже говорилось, в рамках этого курса.

Пакет --- программный компонент, что-то, что может быть отдельно установлено в систему, что либо надо нам, либо требуется другому пакету, который мы используется (разделяемая библиотека, некие данные, которые используются несколькими пакетами). Выстроено дерево зависимостей.

Тут есть такой момент: есть некое программное средство, оно делает некую вещь, у него есть собственно библиотека, консольный интерфейс и интерфейс на kde. В некоторых дистрибутивах это сваливают в один пакет. С другой стороны, если дробить очень мелко, то будет очень мелко и это трудно ментейнить.

Пакет --- это не вещь в себе, а часть системы. Это не просто программный продукт, а программный продукт, адаптированный для работы в составе дистрибутива. Он должен использовать инфраструктуру, предоставляемую дистрибутивом и не противоречить каким-то правилам, которые ... например, есть несколько инструментов, которые делают примерно одно и то же, и создаётся инфраструктура, у которой отдельные элементы можно менять,

Debian policy --- это то, что позволило выжить дебиану, как дистрибутиву. Он достаточно полно описывает архитектуру дистрибутива, описывает устройство бинарных пакетов, каким требованиям должны соответствовать исходные пакеты, требования к скриптам установки, огромное количество системных политик (FHS и его уточнения). Каким образом устанавливаются сценарии init и как осуществляется работа с конфигурационными файлами.

Есть различные дополнительные пакеты.

Или же, например, есть задача пакетирования инструментов на питоне, у него есть собственный взгляд на то, как надо устанавливать инструменты на питоне, там используется каким-то образом стандартная питоновская обвязка, но также используются свои собственные инструменты.

Благодаря полиси дистрибутива дебиан такой вкусный, красивый и удобный.

В частности, для всякого нетривиального случая в /usr/share/doc есть README.debian, где написано, как использовать инструмент.

Формат бинарного пакета: архив ar, сжатый gz или bz2.

Пакет исходных текстов сост из архива ПО от автора (обычно тарбол, но бывают разные случаи), diff.gz, где хранится метаинформация для дистрибутива, правила сборки, изменения в целях интеграции и исправления ошибок.

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

В чём состоит сборка бинарного пакета: у нас есть некий распространяемый программный продукт, нам из него надо сделать бинарный пакет. Если делать всё руками, то мы его его компилируем, раскладываем эти файлы в некоем соответствии с иерархией каталогов (делаем это в отдельном подкаталоге), после это получившееся берём и сжимаем, добавляя некую дополнительную информацию. Для этого была создана утилита dpkg-deb.

Программных продуктов много, и есть идея добавлять каталог debian, где хранится метаинформация.

Впоследствии появился более высокоуровневый инструмент, dpkg-buildpackage

В пакете находится файл debian/control, где находится всякая

В debian/copyright --- указаны, какие лицензии у каких файлов. Есть license-check, который по хитрым регекспам вытягивает лицензии и расставляет копирайты.

В debian/changelog хранится вся история пакета

debian/rules --- на самом деле, мейкфайл, который

Естественно, писать всё руками сложно, поэтому есть различные инструменты для автоматизации.

Базовая система, с помощью которой написано подавляющее количество debian/rules --- debhelper. Например, нам нужно сделать configure-make-make install, после чего распихать файлы по нескольким пакетам. Для этого описывается простенький файл и натравливаются различные утилиты debhelper. Их вызов надо явно прописывать. Неудобно, makefile большой. Для этого решили сделать более высокоуровневое, например "наш проект собирается autoconf", тогда нужно сказать configure с нужным префиксом, и так далее. Для этого был придумана cdbs -- common debian build system, его мейкфайл очень короткий, простой, но не очень понятно, что он там делает внутри.

Дальше, есть у нас diff.gz, там хранятся помимо каталога debian, изменения, хранящиеся в самих файлах апстрима. Но все изменения хранятся в одном диффе, что неудобно. Логично вынести в отдельные патчи, и прописать первым правилом "применить все патчи вот оттуда". Для этого есть quilt и dpatch. Второй реализует ровно то, что сказано, первый умеет применять стеково (например, если не применился патч в середине, то, вероятно, надо что-то поправить).

Также, как и в альте, сборка должна проходить в чистом окружении, а на рабочей машине у нас нечистое окружение. Поэтому надо поставить чрут, и в нём что-то собрать. Для этого есть pbuilder, он работает не совсем так, как хэшер, он достаточно простой. Для начала, нужно развернуть базовую систему (которая сначала создаётся, а потом targz до лучших времён), можно в неё сделать чрут, разворачиваем пакет, вытягиваются и ставятся сборочнеы зависимости, собирается пакет.

Есть инструмент для проверки пакетов: lintian, который проверяет на соответствие полиси и на стандартные ошибки. Автоматизированная проверка скриптов --- puiparts.

Следующий момент --- если мы пакетируем ПО, особенно, совместно, то хорошо бы это хранить в VCS. Кроме того, это позволяет автоматически генерировать чейнджлог и прочие задачи интеграции. Такие системы есть для cvs, svn, git.

Как устроен пакет и его собирают - понятно, а вот что дальше происходит, про это ещё ничего не рассказывалось.

В отличие от многих дистрибутивов где приняты time-based releases, дебиан появляется тогда, когда он готов.

• Есть репозиторий, куда кладут пакеты. В какой-то момент объявляется фриз.
  • Проблема 1. Репозиторий нестабилен
  • Проблема 2. Разработка не оканчивается.
• Соответственно, двухуровневая модель тут начинает не очень приятно работать. Поэтому в дебиане году в 2000 предложена трёхуровневая модель, когда есть unstable, куда кладут пакеты, и он там живёт. Если в течение 10 дней там не обнаружено release-critical багов, то его можно перенести в testing. Естественно, тут требование, что все зависимости тоже должны быть в testing.

Эта трёхуровневая модель в дебиане работает очень удобно.

После попадании пакета в stable изменений версии пакета происходить не должно. Кроме двух случаев:

• Уязвимость по безопасности. При этом версия не меняется.

Как участвовать в проекте:

• Пользователь.
• Ментейнер.
• Девелопер