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

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

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

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

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

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

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

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

Три термина:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Debian policy --- это то, что позволило выжить дебиану, как дистрибутиву. Он достаточно полно описывает арзитектуру дистрибутивы, описывает устройство бин. паеты, каким тркбованиям должн соотв. исх. пакеты, требования к скриптам установки, огромное количество системных политик (FHS и его уточнения)/ Rfrbv j,h/ ecnh/ штше? rfr jceo/ hf,jnf c rjya/ afqkfvb/.

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

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

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

В частности, для всякого нетривиального случае в /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 --- на самом деле, мейкфайл, который

Tcntcndtyyj? gbcfnm dc` herfvb ckj;tj? gj'njve tcсть раздияные инструменты для автоматизации.

Базовая система, с помощью которой написано подавл. количество 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.

Rfr ecnh/ gfrtn b tuj cj,bhf.n? gjyznyj? f djn xnj lfkmit ghjbc[? ghj 'nj to` ybxtuj yt hfccr/

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

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

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

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

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

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

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