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

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

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

* '''Презентация:''' [[Media:Debian.packaging.pdf|PDF]], [[Media:Debian.packaging.pdf|ODP]]

До этого процесс сопровождения был рассмотрен для 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 изменений версии пакета происходить не должно. Кроме двух случаев:
* Уязвимость по безопасности. При этом версия не меняется.

Как участвовать в проекте:
* Пользователь. 
* Ментейнер.
* Девелопер

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2009%2C_06_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_11_%D0%BD%D0%BE%D1%8F%D0%B1%D1%80%D1%8F%29

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

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

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 1: / Строка 1: @@
 * '''Презентация:''' [[Media:Debian.packaging.pdf|PDF]], [[Media:Debian.packaging.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, и хорошо бы рассмотреть, как он устроен в других дистрибутивах, в частности, Дебиан.