На протяжении многих лет sbuild и pbuilder развивались так, чтобы иметь практически одинаковую функциональность, и, поскольку функции добавляются к одному из них, они, как правило, быстро перенимаются другими.
Поскольку пакет Debian является форматом, основанным на политиках, он помогает определить, является ли данная проблема сборки ошибкой в реализации компоновщика или проблемой сборки пакета, имеющей несколько реализаций системы сборки. Чтобы поддерживать это, все ведущие системы сборки должны иметь сильных сторонников, поддерживающих их, в духе совместной конкуренции за обеспечение того, чтобы у нас были наиболее правильные из доступных реализаций политики.
Внутренняя механика sbuild и pbuilder значительно различается, поэтому, какие именно пакеты извлекаются для удовлетворения зависимостей при сборке или как они вытягиваются, точный механизм, с помощью которого вызываются различные цели в debian / rules и т. Д., Может отличаться, вызывая некоторые незначительные различия в поведении в очень специфических случаях для определенных пакетов. В большинстве случаев это представляет собой ошибку в той или иной реализации и иногда отражает отсутствие ясности в политике упаковки: в любом случае изменения поведения должны быть устранены.
Официальные сборки как в Debian, так и в Ubuntu используют sbuild (хотя часто это не sbuild, доступный из архивов), что считается преимуществом для некоторых разработчиков, так как они имеют большую уверенность в том, что их конфигурация соответствует той, которой будет представлен их пакет при сборке, хотя, если все так делают, мы теряем способность отличать ошибки в политике от ошибок в sbuild.
Исторически я понимаю, что разработка pbuilder изначально была ориентирована на потребности разработчика, так как разработка для конечного пользователя и sbuild изначально была ориентирована на потребности администраторов buildd и архива. В последнее время эти фокусы поменялись, поскольку люди создали системы управления архивами на основе pbuilder и более полезные инструменты разработчика, использующие sbuild.
Оба инструмента (или их общедоступные близкие производные) поддерживают хранение chroot в виде архивов, распакованных в системе, в отдельных томах (с доступными хуками для специального монтирования: например, снимки LVM), с использованием наложенных файловых систем, семантики копирования при записи и т. Д. Оба инструмента предлагают тривиальные инструменты командной строки для упрощения общего случая (тест-сборка пакета) и расширенную семантику хуков для поддержки сложных случаев (большие архивы). Оба предоставляют средства для создания тестовой среды в chroot. Короче говоря, оба инструмента предоставляют практически все, что вы могли бы подумать в инструменте построения пакетов (и оба имеют активных апстримов, готовых принимать ошибки и исправления).
В итоге: если вы довольны pbuilder, продолжайте использовать его. Если вы хотите поиграть со sbuild, не стесняйтесь. Лучший инструмент - тот, который вам удобно использовать для той работы, которую вы делаете.
sbuild
, используется для создания пакетов Ubuntu, хотя панель запуска (из того, что я понимаю) работаетpbuilder
...С Эмметом всегда опасно не соглашаться, поэтому позвольте мне начать с признания того, что его ответ, вероятно, более правильный. Тем не менее, я лично считаю 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
против
вердикт: tie , обе командные строки довольно просты, и обе могут при необходимости использовать дополнительные опции для более сложных вариантов использования. Однако обратите внимание на дополнительный новый каталог, созданный pcreate.
Скачать исходный пакет
противы
вердикт: небольшое преимущество для sbuild , потому что вы используете стандартную лучшую практику Debian / Ubuntu. Соглашение, используемое pget, на первый взгляд может показаться странным, но, поскольку я работаю над несколькими пакетами в нескольких выпусках Ubuntu, мне нравится организация, которую он навязывает. Также обратите внимание, что apt-get source также извлекает источник, где бы вы ни выполняли команду, оставляя вам * .orig.tar.gz, * .debian.tar.gz, * .dsc и расширенный каталог, который я лично нахожу для быть грязным Красота организации скоро, я обещаю.
Введите chroot, эфемерная версия
противы
вердикт: небольшое преимущество для pbuild , меньше символов для ввода - меньше символов. Обратите внимание, что в этой версии входа в chroot все внесенные вами изменения будут потеряны после выхода из chroot. Также обратите внимание, что в schroot вы останетесь обычным пользователем, в то время как с ptest вы будете в chroot как пользователь root.
Введите chroot, сохраните изменения версии
противы
вердикт: по моему мнению, небольшое преимущество для pbuild , меньше символов и более интуитивно понятные аргументы командной строки. В этой версии ввода chroot все внесенные в него изменения будут сохранены для будущих вызовов.
Создайте пакет в chroot
противы
вердикт: 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, но я их не знаю.
Надеюсь это поможет.
источник
pbuilder-dist --login --save-after-login
того, чтобы немного подправить среду сборки, потому что, например, мне нужен специальный пакет и его запись sources.list не существует по умолчанию. Так что, кажется, имеет смысл настроить среду chroot.