Зачем использовать sbuild поверх pbuilder?
Существует множество способов сборки пакетов Debian в чистой и воспроизводимой среде. Двумя наиболее часто используемыми являются pbuilder и sbuild. Лично я всегда использовал pbuilder. Я считаю, что pbuilder намного проще в использовании и обслуживании. Я не смог найти ни одного параллельного сравнения двух. Что я упускаю?
Какие преимущества есть в использовании sbuild перед pbuilder?
2 ответа
На протяжении многих лет 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, но я их не знаю.
Надеюсь это поможет.