Почему использование sbuild по pbuilder?
Существуют многочисленные способы создать пакеты Debian в чистой и восстанавливаемой среде. Два из наиболее часто используемого являются pbuilder и sbuild. Лично, я всегда использовал pbuilder. Я нахожу pbuilder намного легче использовать и поддержать. Я не смог найти любого рядом сравнением двух. Что я пропускаю?
Какие преимущества находятся там в использовании sbuild по pbuilder?
2 ответа
sbuild и pbuilder разработали за эти годы, чтобы иметь почти идентичную функциональность, и поскольку опции добавляются к также, они имеют тенденцию быть быстро принятыми другим.
Поскольку упаковка Debian является управляемым политикой форматом, это - значительная помощь в определении, является ли данной проблемой сборки ошибка в реализации разработчика или проблемы с пакетом, создаваемым, чтобы иметь несколько реализаций системы сборки. Для поддержания этого ведущие системы сборки должны все иметь сильных приверженцев, поддерживающих их в духе совместной конкуренции к обеспечению, чтобы у нас были самые корректные доступные реализации политики.
Внутренняя механика sbuild и pbuilder значительно отличается, так точно, какие пакеты вытягивают для удовлетворения зависимостей сборки или как их вытягивают, точный механизм, которым различные цели в debian/rules называют, и т.д. может отличаться, вызывая некоторые незначительные различия в поведении в очень конкретных случаях для определенных пакетов. Большую часть времени это представляет ошибку в одной или другой реализации, и иногда отражает отсутствие ясности в упаковочной политике: в любом случае изменения поведения должны быть разрешены.
Официальные buildds и в Debian и в Ubuntu используют sbuild (хотя часто не sbuild доступное из архивов), который считают преимуществом некоторые разработчики, поскольку у них есть большая уверенность, что их соответствия конфигурации, что, которому будет выставлен их пакет при создании, хотя, если все делают это, мы теряем способность отличить ошибки в политике от ошибок в sbuild.
Исторически, мое понимание то, что pbuilder разработка, первоначально сфокусированная на потребностях разработчика как конечный пользователь и sbuild разработка, первоначально сфокусированная на потребностях buildd и архива adminstrators. Недавно, эти фокусы переключились, поскольку люди создали системы управления архивами на основе pbuilder и более полезные инструменты разработчика с помощью sbuild.
Оба инструмента (или их обычно доступные близкие производные) поддержка, хранящая chroots как tarballs, распакованный в системе, в отдельных объемах (с доступными рычагами для специального монтирования: например, снимки LVM), с помощью файловых систем наложения, с помощью семантики копии на записи, и т.д. Оба инструмента предлагают тривиальные инструменты командной строки для оптимизации общего падежа (тестовая сборка пакет) и богатая семантика рычага для поддержки сложных случаев (крупные архивы). Оба обеспечивают средство создать тестовую среду в chroot. Короче говоря, оба инструмента обеспечивают примерно что-либо, что Вы могли бы думать, что хотели в инструменте разработки пакета (и у обоих есть активные восходящие потоки, счастливые принять ошибки и патчи).
Таким образом: если Вы довольны pbuilder, продолжайте использовать его. Если Вы хотите играть с sbuild, не стесняться. Лучший инструмент является тем, который Вы - удобное использование для вида работы, которую Вы делаете.
Всегда опасно не согласиться с Муравьем, таким образом позвольте мне начаться путем подтверждения, что его ответ, вероятно, более корректен. Однако я лично нахожу pbuilder более удобный для пользователя и более производительный из поля.
Если Вы находитесь на Ubuntu 12.10 или позже, несомненно, установите превосходные pbuilder-сценарии, которые являются рядом чрезвычайно дружественных оберток вокруг сырых данных pbuilder.
Если Вы находитесь на Ubuntu 12.04, можно установить pbuilder-сценарии из репозитория бэкпортов.
Теперь, давайте сравним и давайте контрастировать удобные для пользователя из эквивалентных операций. В этих примерах я буду идти посредством использования ARM chroot размещенный на x86, но понятия все еще относятся к x86 chroot, размещенному на x86 также. Помните, я использую обертки pbuilder-сценариев.
Одна вещь отметить состоит в том, что 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
вердикт: свяжите, обе командных строки довольно просты, и оба могут выбрать дополнительные варианты для более необычных вариантов использования в случае необходимости. Однако отметьте дополнительный новый каталог, созданный 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, мне нравится организация, которую это налагает. Обратите внимание также, что склонный - добираются, источник также извлекает источник везде, куда Вы выполняете команду, оставляя Вас с *.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 загрузят и установят сборку-deps в их соответствующем chroots. Однако pbuild сохранил загруженные .deb файлы в / var, поэтому при вызове pbuild во второй раз, когда Вы не должны загружать всю сборку-deps снова (хотя они должны все еще быть установлены в chroot). sbuild не кэширует .deb файлы (по крайней мере, не по умолчанию), и поэтому, необходимо загрузить всю сборку-deps снова в дополнение к ожиданию их, чтобы быть установленными в chroot.
вердикт: pbuild намного. Кэширование сборки-deps является большой настройкой по умолчанию, и pbuild достаточно умен, чтобы обнаружить, если существует более новая версия DEP сборки в архиве, и будет выпадающий новая версия при необходимости. Поскольку сложный пакет со многими создает-deps, эта простая установка сохранит Вас минуты Вашей жизни.
Сводка
Из поля я нахожу, что pbuilder-сценарии являются намного более дружественными и быстрее, чем sbuild эквиваленты. Конечно, существуют способы сделать pbuilder еще быстрее (сборка в tmpfs, отключить некоторые рычаги chroot), и существуют, вероятно, те же приемы для sbuild также, но я не знаю о них.
Надеюсь, это поможет.