Два важных исправления в то, что говорили ранее.

  1. В федоре 4-ый рпм, не 5-ый. В федоре на него не перешли по причине скандала.
  2. Описывали формат срц файла. формат - урл - эцп - название репозитория -- разделы репо. Говорили, что эцп относилось к пакетам, а на самом деле подписан репо. Ключи, которыми подписаны пакеты просто должны присутствовать в кейринге на момент проверки подписи. В альте с ними отдельный пакет.

Debian specific

Обещали рассказать про сборку пакетов в дебиане, попалась презентация лукаса нубаумана, Debian packaging tutorial. Всем, кто собирается собирать пакеты в дебиане -- рекомендуется начинать именно с него. Во первых потому что он зверски актуален -- 2013 года. Во-вторых, он расскзаывает о главном и отсылает за всем остальным к документации, что нам очень актуально.

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

Перввая часть разговора -- воспроизвестии этот документ.

ar-формат

deb пакет это просто архив, но, в отличие от рпма деб пакет это ar архив. С помощью этой утилиты делаются статические библиотеки. tar -- tape archivator -- программа для записи на магнитную ленту. А ar -- просто архиватор. В этом архиве содержатся три файла.

  1. Один описывает формат пакета. Это сделано для обратной совместимости, чтобы старые утилиты для работы с пакетами могли бы понять, что это слишком новый пакет и не пытались его жевать.
  2. Информация о пакете, всякая. Инструкция по установке, системный сценарий итд. control.tar.gz
  3. Собственно файлы, которые надо распаковать.

установка build-essential, devscripts

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

apt-get builddev

Мы про неё не говорили. "Как одной командой поставить все сборочные зависимости данного пакета." Комментарий -- им можно случайно переустановить все пакеты системы.

Добыть пакет с исходниками

В дебиане нет такого, что штука с исходниками тоже пакет. Достаточно скачать три файла

  1. dsc
  2. пакет_версии_orig.tar.gz . Планировалось, что в этом месте будет тарболл апстрима. Но апстрим очень редко выкладывает тарболлы, то это уже перепакованный, но не модифицированный апстрим.
  3. Старая версия -- патчи. Большая часть этих патчей накладывалась на /dev/null. Из него вылезали правила сборки, итд. Достаточно странный способ архивировать много файлов в один -- делать рекурсивный патч, который патчит частично исходники, а частично девнулл. В случае своременной процедуры сборки там будет выглядеть как-то так пакет.версия.debian.tar.gz -- файлы, которые нужны для сборки пакета из этого исходника. Что это за файлы? Их довольно много (создается кталог deb):
    1. Главный файл -- control (паспорт). Аналог первой секции рпм. Информация об исходниках, как собирать.
    2. Makefile -- rules. Синтаксис мейка, но все действия проделываются с помощью специальных сборочных скриптов дебиана. Можете к нему относится, как к файлу со специальным синтаксисом и специальными ключевыми словами
      • много таргетов. Существенно больше, чем секций в рпме. В рпме мы вынуждены все действия с пакетом складывать в одну секцию билд, а в дебиане для каждого действия есть свой таргет. Правда, когда таргетов слишком много -- начинаешь теряться.
      • поддерживаются отдельно архитектурно зависимые и независимые таргеты.
      • как правило, если вы хотите только читать -- то они сами за себя говорят.
    3. copyright
    4. changelog . Идея -- облегчить другому человеку возможность работать с этим пакетом. В нём майнтейнер пишет, что пришлось делать с исходниками, чтобы они снова заработали. Там достаточно сложный формат. Точно также как в рпме есть разделение на версию апстрима и версию сборки. Точно также можно указать архитектуру, для которой собирается пакет, что для дебиана актуально. Можете указать тип пакета, который архитектурно независим (аналог noarch). Это всё указывается в файле контрол.

apt-get source

Автоматизирует скачивание вышеуказанных трех файлов. А в современном мире есть ещё dpkg-checkout который может извлекать файли из свна и гита. То есть, современные деб пакеты могут храниться как файлами, так и в системе контроля версий. Последнее всё более и более приобретает популярность. Во многих случая удобней брать исходный пакет из системы контроля версий.

Ещё про rules

Вот тут начинается дебиан специфик не только в названии и терминлогии, но идеологиечксий. Какие команды вписывать в рулез? В 2 процента пакетов туда вписаны стандартные команды. Остальные пользуются make - helper ами. Помните макрос конфигуре из рпма? Все, кто собираются автотулсами, пользуются файлом конфигур, у которого достаточно много параметров. Именно поэтому удобно сделать макрос. У дебиана мейк-хелперов три разных набора. Года три назад они использовались с одинаковой частотой. Самый новый из них dh7 вроде как киллер предыдущих вариантов, но согласно докладу их всё же три

  1. debhelper -- самый старый (36%)
  2. cdbs (21 %)
  3. dh7 -- (41%) -- самый новый.

Доля cdbs потихоньку падает. По этой причине у нас нет времени рассматривать каждую из этих хелпер систем, сотановимся только на том, что все они сделаны для повышения читаемости rules. В dh есть довольно большая система умолчаний, которая позволяет вообще почти ничего не писать в рулез. "У него там симейк, сделай, как принято у симейк", итп.

Как собрать пакет?

debuilder приводит к запуску dpkg-package build, потом проверяет с помощью специального тестера, потом подписывает. Дебилдер это штука требующая всего, что описано выше, все эти пакеты должны стоять. И, как было верно сказано. попытку поставить сборочные зависимости чему-нибудь экзотическому может привсти к тому, что у вас подтянуться старые версии половины пакетов в системе. Какие альтернативы?

pbuilder (сборка в chroot)

Организует сборочное окружение в чруте. chroot -- системный вызов, который изолирует процесс интересным образом -- меняет окружение так, что он считает корнем тот каталог, который вы передали в параметр чруту. Зачем это нужно? Сборочные зависимости можно вытягивать не в свою живую систему, а в чрут. Чем это хорошо? Вы не ставите сборочные зависимости в хост систему. Если пакет, который вы устанавливаете, написан с невысокой долей разумности, то ставя его в чрут вы никак не модифицируете хост систему. Второй бонус -- вы можете вопсользоватьс ядля создания сборочного окружения не тем хранилищем, на которое настроена ваша хост система. Отвзяать пакетное наполнение хост системы от пакетного наполнения сборочной системы.

sbuild

Если мало pbuilder . Оперирует чуть ли не виртуальными машинами, используется на сборочных серверах дебиана.

Обновления апстрима

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

Автоматического оповещения, в отличие от федоры, вроде бы нет.

Каталог patches

Подкаталог debian. Лет 15 назад, когда всё это придумывали, в исходника было, например, целых 10 файлов на си, и к нему, например, целых два патча -- меняет представления апстрима о том, где лежать пользовательские файлы, второй исправлял грубую ощшибку. Порядок применения патчей был неважен.

На сегодняшний день ситуация такая -- всего лишь 5000 файлов на с++, к нему всего лишь 40 патчей. 40 это редкость, но, например, ISC с bind и dhcp -- ровно так. У рпма и центоса может автогенериться по 100-200 патчей.

quilt

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

В частности, он позволяет работать с патч сериями и патч сетами.

На этом про дебиан временно всё.

Изолированная сборка

Что это такое и зачем нужно?

Одну вещь мы уже видели. Эта вещь говорит о том, что лучше ставить сборочные зависимости в чрут и получили бы двойной бонус -- не загадивали бы хост систему и обеспечили бы возможность поставтить в сборочное окружение пакеты из отличного от хостсистемного репо.

Требования

Какие требования мы могли бы предъявить изолированной сборке?

Немодификация хост системы

Одна вещь про пбилдер. Установка пакетов и работа с фс внутри чрута, казалось бы, может вестись от рута. Казалось бы, когда мы ставим в чрут, такой проблемы нет, но это не так. Кто может ручаться, что приехавшее конфигуре не создаст устройства от рута и не начнет там куролесить. То есть, чрут нас, теоретически не защищает от возможности взлома, да и практически -- если есть суперпользователь, то чрут не чрут.

Итого, действия в чруте должны производится не от настойщего рута.

В современном мире цена этих вещей уменьшается. Уже скоро будет не проблемой быстро развернуть сборочную виртуалку. Но, пока, разворачивание виртуальной машины по профилю операция более сложная, чем устанвока пакета в чрут, эта штука будет актуальна.

Что здесь надо соблюдать? Последовательность действий.

  1. взять чрут, развернуть из тарболла пакеты, поставить в чрут сборочные зависимости ( с правами рутера)
  2. с правами обычного пользователя положить исходники
  3. с правами билдера их собрать внутри окружения и положить в место, доступное юзеру, результат .
  4. юзер забирает результат
  5. билдер всё удаляет
  6. рутер всё удаляет

С правами пользователя мы тут только закладываем файлы и вынимаем файлы.

По такой схеме работает hasher в альтлинуксе.

Особенности сборки в хэшер. Главная особенность -- лектор теперь почти никогда не собирает и не редактирует пакеты в хост системе. Среди утлит хэшер существует утилита hsh-shell которая запускает в чруте шелл с правами рутера. Вот там то всё и делается. Небольшой скрипт ставит туда zsh, vim копирует туда все нужные настройки. После этого можно с помощью hsh-install смело ставить туда пакеты, как если бы устанавливал пакеты в хост систему.

Некоторое время назад хэшер рассматривался как очень легкая реализация изоляции.

Что можно прокинуть в хэшер?

  1. Сеть. По умолчанию выключено, но можно прокинуть.
  2. X11 .

Что ещё интересного может быть с хэшером? Тот каталог, в который он кладер результат, можно подключать как репозиторий в sources.list. Этот репозиторий можно использовать для дальнейшей сборки других пакетов в хэшере. Допустим, вы сбоираете библиотеку, а потом программы с ней. Очевидно, что надо, чтобы пакет с этой библиотекой был доступен при сборке новых пакетов. Так делает по умолчанию. Но такое поведение можно поменять опцией хэшера при запуске.

Чем ещё часто пользуются в хэшере?

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

Сам хэшер запускается как hsh ... src.rpm

--lazy -- не делать полный клинап.

Для того, чтобы воспользоваться хэшером надо иметь право его запускать, то есть добавить вс пециальные группы. Командочка hsh-useradd и перелогиниться.

По умолчанию чрут разворачивается в ~/hasher/chroot . Если эта штука будет в тмпфсе, разворчивание хэшера будет происходить раз в пять бытсрее. тмпфс по скорости чтения не сравним даже с ссд. Считается хорошим тоном у сборочных машин делать большой своп.

Мораль -- изолированная сборка требует больше ресурсов, чем сборка в хост системе, но это её единственный недостаток.

Репозитории лучше держать больше. sisyphus-mirror. Сизиф сейчас занимает порядка 20 гигабайт. Ежеденевные обновления небольшие.

LecturesCMC/PackageMaintaining2013/Conspects/05 (last edited 2013-04-05 15:48:36 by Allena)