Два важных исправления в то, что говорили ранее.
- В федоре 4-ый рпм, не 5-ый. В федоре на него не перешли по причине скандала.
- Описывали формат срц файла. формат - урл - эцп - название репозитория -- разделы репо. Говорили, что эцп относилось к пакетам, а на самом деле подписан репо. Ключи, которыми подписаны пакеты просто должны присутствовать в кейринге на момент проверки подписи. В альте с ними отдельный пакет.
Debian specific
Обещали рассказать про сборку пакетов в дебиане, попалась презентация лукаса нубаумана, Debian packaging tutorial. Всем, кто собирается собирать пакеты в дебиане -- рекомендуется начинать именно с него. Во первых потому что он зверски актуален -- 2013 года. Во-вторых, он расскзаывает о главном и отсылает за всем остальным к документации, что нам очень актуально.
В принципе, прочтя этот докусмнет и майнтейнерс мануал, лектор понял, что особой илдеологической разницы в этом плане между альтом и деьианом нет.
Перввая часть разговора -- воспроизвестии этот документ.
ar-формат
deb пакет это просто архив, но, в отличие от рпма деб пакет это ar архив. С помощью этой утилиты делаются статические библиотеки. tar -- tape archivator -- программа для записи на магнитную ленту. А ar -- просто архиватор. В этом архиве содержатся три файла.
- Один описывает формат пакета. Это сделано для обратной совместимости, чтобы старые утилиты для работы с пакетами могли бы понять, что это слишком новый пакет и не пытались его жевать.
- Информация о пакете, всякая. Инструкция по установке, системный сценарий итд. control.tar.gz
- Собственно файлы, которые надо распаковать.
установка build-essential, devscripts
Все инструменты, которые нужны для сборки. В альте такого нет, почему -- поговрим чуть позже. В дебиане этот инструмент имеет более длинную историю и существенно более широкий. Что такое debuild? Видимо это такой простой способ вызвать обычную сборку пакетов из исходников.
apt-get builddev
Мы про неё не говорили. "Как одной командой поставить все сборочные зависимости данного пакета." Комментарий -- им можно случайно переустановить все пакеты системы.
Добыть пакет с исходниками
В дебиане нет такого, что штука с исходниками тоже пакет. Достаточно скачать три файла
- dsc
- пакет_версии_orig.tar.gz . Планировалось, что в этом месте будет тарболл апстрима. Но апстрим очень редко выкладывает тарболлы, то это уже перепакованный, но не модифицированный апстрим.
- Старая версия -- патчи. Большая часть этих патчей накладывалась на /dev/null. Из него вылезали правила сборки, итд. Достаточно странный способ архивировать много файлов в один -- делать рекурсивный патч, который патчит частично исходники, а частично девнулл. В случае своременной процедуры сборки там будет выглядеть как-то так пакет.версия.debian.tar.gz -- файлы, которые нужны для сборки пакета из этого исходника. Что это за файлы? Их довольно много (создается кталог deb):
- Главный файл -- control (паспорт). Аналог первой секции рпм. Информация об исходниках, как собирать.
- Makefile -- rules. Синтаксис мейка, но все действия проделываются с помощью специальных сборочных скриптов дебиана. Можете к нему относится, как к файлу со специальным синтаксисом и специальными ключевыми словами
- много таргетов. Существенно больше, чем секций в рпме. В рпме мы вынуждены все действия с пакетом складывать в одну секцию билд, а в дебиане для каждого действия есть свой таргет. Правда, когда таргетов слишком много -- начинаешь теряться.
- поддерживаются отдельно архитектурно зависимые и независимые таргеты.
- как правило, если вы хотите только читать -- то они сами за себя говорят.
- copyright
- changelog . Идея -- облегчить другому человеку возможность работать с этим пакетом. В нём майнтейнер пишет, что пришлось делать с исходниками, чтобы они снова заработали. Там достаточно сложный формат. Точно также как в рпме есть разделение на версию апстрима и версию сборки. Точно также можно указать архитектуру, для которой собирается пакет, что для дебиана актуально. Можете указать тип пакета, который архитектурно независим (аналог noarch). Это всё указывается в файле контрол.
apt-get source
Автоматизирует скачивание вышеуказанных трех файлов. А в современном мире есть ещё dpkg-checkout который может извлекать файли из свна и гита. То есть, современные деб пакеты могут храниться как файлами, так и в системе контроля версий. Последнее всё более и более приобретает популярность. Во многих случая удобней брать исходный пакет из системы контроля версий.
Ещё про rules
Вот тут начинается дебиан специфик не только в названии и терминлогии, но идеологиечксий. Какие команды вписывать в рулез? В 2 процента пакетов туда вписаны стандартные команды. Остальные пользуются make - helper ами. Помните макрос конфигуре из рпма? Все, кто собираются автотулсами, пользуются файлом конфигур, у которого достаточно много параметров. Именно поэтому удобно сделать макрос. У дебиана мейк-хелперов три разных набора. Года три назад они использовались с одинаковой частотой. Самый новый из них dh7 вроде как киллер предыдущих вариантов, но согласно докладу их всё же три
- debhelper -- самый старый (36%)
- cdbs (21 %)
- 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
Утилита для работы с развернутыми исходниками будущего пакета, которая в числе прочего, позволяет работать с патчами, редактировать их.
В частности, он позволяет работать с патч сериями и патч сетами.
На этом про дебиан временно всё.
Изолированная сборка
Что это такое и зачем нужно?
Одну вещь мы уже видели. Эта вещь говорит о том, что лучше ставить сборочные зависимости в чрут и получили бы двойной бонус -- не загадивали бы хост систему и обеспечили бы возможность поставтить в сборочное окружение пакеты из отличного от хостсистемного репо.
Требования
Какие требования мы могли бы предъявить изолированной сборке?
Немодификация хост системы
Одна вещь про пбилдер. Установка пакетов и работа с фс внутри чрута, казалось бы, может вестись от рута. Казалось бы, когда мы ставим в чрут, такой проблемы нет, но это не так. Кто может ручаться, что приехавшее конфигуре не создаст устройства от рута и не начнет там куролесить. То есть, чрут нас, теоретически не защищает от возможности взлома, да и практически -- если есть суперпользователь, то чрут не чрут.
Итого, действия в чруте должны производится не от настойщего рута.
fakeroot . С помощью LD_PRELOAD перегружаются вызовы библиотек, возвращающие идентификатор пользователя. Программа, начинает считать запущенной себя от рута. Кроме LD_PRELOAD ещё ведётся журнал действий, которые не было возможно делать, потому что это был ненастойщий рут. Например, программа попыталась создать устройства -- это заметили и учли на будущее (не создавая устройство на самом деле).
- Ещё одно требование. Немодификация сборочного окружения. Если вы посмотрите на многие пакеты многих дистрибутивов, вы увидите там секцию clean. Пожалуйста удали всё то, что я вот там насобирала. Это наводит нас на то, что с целью экономии времени, сборочное окружение не разворачивается отдельно для каждого пакета, а сохраняется. Чтобы пакет не влиял на следующий, он должен за собой подчистить. Вообще говоря это плохо, потому что мы не можем быть уверены, что clean был написан верно и честно. Единственный способ гарантировать чистое сборочное окружение -- развернуть его с нуля. Это тяжёлая операция, оно порядка 200 с гаком мегабайт. Есть много спосбов это обойти.
- Немодификация задним числом непривилегированного сборочного окружения. Чтобы ни файлы, ни переменный окружения собирающего пользователя не пострадали. Это означает, что в fakeroot будут на самом деле два пользователя -- рут и билдер. Оба из которых не равны настоящему собирающему пользователю.
В современном мире цена этих вещей уменьшается. Уже скоро будет не проблемой быстро развернуть сборочную виртуалку. Но, пока, разворачивание виртуальной машины по профилю операция более сложная, чем устанвока пакета в чрут, эта штука будет актуальна.
Что здесь надо соблюдать? Последовательность действий.
- взять чрут, развернуть из тарболла пакеты, поставить в чрут сборочные зависимости ( с правами рутера)
- с правами обычного пользователя положить исходники
- с правами билдера их собрать внутри окружения и положить в место, доступное юзеру, результат .
- юзер забирает результат
- билдер всё удаляет
- рутер всё удаляет
С правами пользователя мы тут только закладываем файлы и вынимаем файлы.
По такой схеме работает hasher в альтлинуксе.
Особенности сборки в хэшер. Главная особенность -- лектор теперь почти никогда не собирает и не редактирует пакеты в хост системе. Среди утлит хэшер существует утилита hsh-shell которая запускает в чруте шелл с правами рутера. Вот там то всё и делается. Небольшой скрипт ставит туда zsh, vim копирует туда все нужные настройки. После этого можно с помощью hsh-install смело ставить туда пакеты, как если бы устанавливал пакеты в хост систему.
Некоторое время назад хэшер рассматривался как очень легкая реализация изоляции.
Что можно прокинуть в хэшер?
- Сеть. По умолчанию выключено, но можно прокинуть.
- X11 .
Что ещё интересного может быть с хэшером? Тот каталог, в который он кладер результат, можно подключать как репозиторий в sources.list. Этот репозиторий можно использовать для дальнейшей сборки других пакетов в хэшере. Допустим, вы сбоираете библиотеку, а потом программы с ней. Очевидно, что надо, чтобы пакет с этой библиотекой был доступен при сборке новых пакетов. Так делает по умолчанию. Но такое поведение можно поменять опцией хэшера при запуске.
Чем ещё часто пользуются в хэшере?
--clean-up -- выполняет две последние стадии, после чего чрут может удалить юзер. Если сборка не прошла успешно, то клинап не выполняет.
Сам хэшер запускается как hsh ... src.rpm
--lazy -- не делать полный клинап.
Для того, чтобы воспользоваться хэшером надо иметь право его запускать, то есть добавить вс пециальные группы. Командочка hsh-useradd и перелогиниться.
По умолчанию чрут разворачивается в ~/hasher/chroot . Если эта штука будет в тмпфсе, разворчивание хэшера будет происходить раз в пять бытсрее. тмпфс по скорости чтения не сравним даже с ссд. Считается хорошим тоном у сборочных машин делать большой своп.
Мораль -- изолированная сборка требует больше ресурсов, чем сборка в хост системе, но это её единственный недостаток.
Репозитории лучше держать больше. sisyphus-mirror. Сизиф сейчас занимает порядка 20 гигабайт. Ежеденевные обновления небольшие.