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

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

Перейти к: навигация, поиск

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

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

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

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


UNИX, осень 2009


00 01 02 03 04 05 06 07 08 09 10 11


Календарь

Сентябрь
23 30
Октябрь
07 14 21 28
Ноябрь
11 18 25
Декабрь
02 09 16


Эта статья является конспектом лекции.

Эта статья ещё не вычитана. Пожалуйста, вычитайте её и исправьте ошибки, если они есть.
Личные инструменты
Разделы