Редактирование: UNИX, осень 2009, 06 лекция (от 11 ноября)

* реакция на сообщения об ошибках

* 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/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, дебиан появляется тогда, когда он готов.

* Есть репозиторий, куда кладут пакеты. В какой-то момент объявляется фриз.

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

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

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

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