Зачем использовать sbuild поверх pbuilder?

Существует множество способов сборки пакетов Debian в чистой и воспроизводимой среде. Двумя наиболее часто используемыми являются pbuilder и sbuild. Лично я всегда использовал pbuilder. Я считаю, что pbuilder намного проще в использовании и обслуживании. Я не смог найти ни одного параллельного сравнения двух. Что я упускаю?

Какие преимущества есть в использовании sbuild перед pbuilder?

На протяжении многих лет sbuild и pbuilder развивались так, чтобы иметь практически одинаковую функциональность, и, поскольку функции добавляются к одному из них, они, как правило, быстро перенимаются другими.

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

Внутренняя механика sbuild и pbuilder значительно различается, поэтому, какие именно пакеты извлекаются для удовлетворения зависимостей при сборке или как они вытягиваются, точный механизм, с помощью которого вызываются различные цели в debian / rules и т. Д., Может отличаться, вызывая некоторые незначительные различия в поведении в очень специфических случаях для определенных пакетов. В большинстве случаев это представляет собой ошибку в той или иной реализации и иногда отражает отсутствие ясности в политике упаковки: в любом случае изменения поведения должны быть устранены.

Официальные сборки как в Debian, так и в Ubuntu используют sbuild (хотя часто это не sbuild, доступный из архивов), что считается преимуществом для некоторых разработчиков, так как они имеют большую уверенность в том, что их конфигурация соответствует той, которой будет представлен их пакет при сборке, хотя, если все так делают, мы теряем способность отличать ошибки в политике от ошибок в sbuild.

Исторически я понимаю, что разработка pbuilder изначально была ориентирована на потребности разработчика, так как разработка для конечного пользователя и sbuild изначально была ориентирована на потребности администраторов buildd и архива. В последнее время эти фокусы поменялись, поскольку люди создали системы управления архивами на основе pbuilder и более полезные инструменты разработчика, использующие sbuild.

Оба инструмента (или их общедоступные близкие производные) поддерживают хранение chroot в виде архивов, распакованных в системе, в отдельных томах (с доступными хуками для специального монтирования: например, снимки LVM), с использованием наложенных файловых систем, семантики копирования при записи и т. Д. Оба инструмента предлагают тривиальные инструменты командной строки для упрощения общего случая (тест-сборка пакета) и расширенную семантику хуков для поддержки сложных случаев (большие архивы). Оба предоставляют средства для создания тестовой среды в chroot. Короче говоря, оба инструмента предоставляют практически все, что вы могли бы подумать в инструменте построения пакетов (и оба имеют активных апстримов, готовых принимать ошибки и исправления).

В итоге: если вы довольны pbuilder, продолжайте использовать его. Если вы хотите поиграть со sbuild, не стесняйтесь. Лучший инструмент - тот, который вам удобно использовать для той работы, которую вы делаете.

С Эмметом всегда опасно не соглашаться, поэтому позвольте мне начать с признания того, что его ответ, вероятно, более правильный. Тем не менее, я лично считаю pbuilder более удобным для пользователя и более производительным из коробки.

Если вы работаете в Ubuntu 12.10 или более поздней версии, обязательно установите отличные скрипты pbuilder, которые представляют собой набор чрезвычайно удобных оболочек для raw pbuilder.

Если вы используете Ubuntu 12.04, вы можете установить pbuilder-scripts из репозитория backports.

Теперь давайте сравним и сопоставим удобство эквивалентных операций. В этих примерах я рассмотрю использование chroot ARM, размещенного на x86, но концепции все еще применимы к chroot x86, размещенному на x86. Помните, я использую упаковщики pbuilder-scripts.

Следует отметить, что сценарии pbuilder реализуют некоторые соглашения, аналогично тому, как Ruby on Rails принимает некоторые решения для вас, чтобы вы могли быстро приступить к работе. Я постараюсь указать на это, как мы идем.

Создать chroot

mk-sbuild --arch=armhf quantal

против

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

вердикт: tie , обе командные строки довольно просты, и обе могут при необходимости использовать дополнительные опции для более сложных вариантов использования. Однако обратите внимание на дополнительный новый каталог, созданный pcreate.

Скачать исходный пакет

# standard debian/ubuntu method, works in any directory
apt-get source casper

противы

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

вердикт: небольшое преимущество для sbuild , потому что вы используете стандартную лучшую практику Debian / Ubuntu. Соглашение, используемое pget, на первый взгляд может показаться странным, но, поскольку я работаю над несколькими пакетами в нескольких выпусках Ubuntu, мне нравится организация, которую он навязывает. Также обратите внимание, что apt-get source также извлекает источник, где бы вы ни выполняли команду, оставляя вам * .orig.tar.gz, * .debian.tar.gz, * .dsc и расширенный каталог, который я лично нахожу для быть грязным Красота организации скоро, я обещаю.

Введите chroot, эфемерная версия

schroot -c quantal-armhf

противы

ptest quantal-armhf

вердикт: небольшое преимущество для pbuild , меньше символов для ввода - меньше символов. Обратите внимание, что в этой версии входа в chroot все внесенные вами изменения будут потеряны после выхода из chroot. Также обратите внимание, что в schroot вы останетесь обычным пользователем, в то время как с ptest вы будете в chroot как пользователь root.

Введите chroot, сохраните изменения версии

sudo schroot -c quantal-armhf-source -u root

противы

ptest quantal-armhf --save

вердикт: по моему мнению, небольшое преимущество для pbuild , меньше символов и более интуитивно понятные аргументы командной строки. В этой версии ввода chroot все внесенные в него изменения будут сохранены для будущих вызовов.

Создайте пакет в chroot

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

противы

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

вердикт: pbuild , теперь мы видим первый значительный выигрыш при использовании соглашений pbuild. Это очень простая команда, которую больше не нужно запоминать, в отличие от указания архитектуры, имени chroot и указания пути к файлу * .dsc, который требуется для sbuild. Кроме того, вы должны не забыть сгенерировать новый файл * .dsc с помощью sbuild, тогда как pbuild сделает это автоматически.

Сборка того же пакета в chroot, во второй раз

В приведенном выше примере и sbuild, и pbuild загрузят и установят build-deps в своих соответствующих chroot-файлах. Тем не менее, pbuild сохраняет загруженные файлы .deb в / var, поэтому, если вы вызываете pbuild во второй раз, вам не нужно загружать все сборочные файлы снова (хотя они все равно должны быть установлены в chroot). sbuild не кэширует файлы .deb (по крайней мере, по умолчанию), и поэтому вы должны снова загрузить все сборочные файлы в дополнение к ожиданию их установки в chroot.

вердикт: pbuild от дальнего удара. Кэширование build-deps является отличным параметром по умолчанию, и pbuild достаточно умен, чтобы определить, есть ли в архиве более новая версия build-dep, и при необходимости запустит новую версию. Для сложного пакета с множеством сборок эта простая настройка сэкономит вам минуты вашей жизни.

Резюме

Из коробки я нахожу, что скрипты pbuilder намного удобнее и быстрее, чем эквиваленты sbuild. Конечно, есть способы сделать pbuilder еще более быстрым (встроить tmpfs, отключить некоторые из обработчиков chroot), и, вероятно, есть те же приемы и для sbuild, но я их не знаю.

Надеюсь это поможет.