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

Похоже, что пустой пароль не соответствует требованиям к сложности пароля.

Это то, что я нашел в man passwd

As a general guideline, passwords should consist of 6 to 8 characters including one or
       more characters from each of the following sets:

       ·   lower case alphabetics

       ·   digits 0 thru 9

       ·   punctuation marks

       Care must be taken not to include the system default erase or kill characters.  passwd will reject any password which is not
       suitably complex.

EDIT: К сожалению, вы не можете установить пароль для пустого через этот пользовательский интерфейс.

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/gnome-control-center/quantal-proposed/view/head:/panels/user-accounts/um-password -dialog.c # L358

- это функция, которая решает, следует ли включать кнопку «Изменить» или нет.

    if (strlen (password) < MIN_PASSWORD_LEN) {
            can_change = FALSE;
            if (password[0] == '\0') {
                    tooltip = _("You need to enter a new password");
            }
            else {
                    tooltip = _("The new password is too short");
            }
    }
    else if (strcmp (password, verify) != 0) {
            can_change = FALSE;
            if (verify[0] == '\0') {
                    tooltip = _("You need to confirm the password");
            }
            else {
                    tooltip = _("The passwords do not match");
            }
    }
    else if (!um->old_password_ok) {
            can_change = FALSE;
            if (old_password[0] == '\0') {
                    tooltip = _("You need to enter your current password");
            }
            else {
                    tooltip = _("The current password is not correct");
            }
    }
    else {
            can_change = TRUE;
            tooltip = NULL;
    }

    gtk_widget_set_sensitive (um->ok_button, can_change);

Минимальный пароль len 6 жестко запрограммирован: (

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/gnome-control-center/quantal-proposed/view/head:/panels/user-accounts/um- password-dialog.c # L358

#define MIN_PASSWORD_LEN 6

20
задан 14 July 2011 в 04:17

18 ответов

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

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

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

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

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

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

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

26
ответ дан 25 May 2018 в 19:50
  • 1
    Интересно, что вы говорите, что sbuild используется для создания пакетов Ubuntu, даже если пусковая панель (из того, что я понимаю) запускает pbuilder ... – Alexis Wilke 25 July 2016 в 03:27

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

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

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

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

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

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

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

26
ответ дан 25 July 2018 в 21:35

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

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

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

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

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

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

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

26
ответ дан 31 July 2018 в 10:35

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

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

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

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

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

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

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

26
ответ дан 31 July 2018 в 11:38

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

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

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

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

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

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

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

26
ответ дан 2 August 2018 в 03:12

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

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

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

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

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

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

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

26
ответ дан 4 August 2018 в 19:06

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

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

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

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

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

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

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

26
ответ дан 6 August 2018 в 03:24

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

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

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

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

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

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

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

26
ответ дан 7 August 2018 в 21:10

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

[ f7]

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

[d40 ] Надеюсь, это поможет.

18
ответ дан 25 May 2018 в 19:50
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 25 July 2018 в 21:35
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 31 July 2018 в 10:35
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 31 July 2018 в 11:38
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 2 August 2018 в 03:12
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 4 August 2018 в 19:06
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 6 August 2018 в 03:24
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

extreme

mk-sbuild --arch=armhf quantal

vs

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

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

tie

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

vs.

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

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

Маленькое ребро для sbuild

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

небольшое ребро для pbuild

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

vs.

ptest quantal-armhf --save

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

небольшое ребро для pbuild

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

vs.

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

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

pbuild

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

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

pbuild

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

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

18
ответ дан 7 August 2018 в 21:10
  • 1
    pget выглядит ужасно похоже на «pull-lp-source» из пакета ubuntu-dev-tools. apt-get source - это то, что я обычно не использую для дистрибутива. Он нацелен на пользователей, поэтому они могут сказать «дайте мне источник этого пакета», а не разработчикам. – SpamapS 28 November 2012 в 01:01
  • 2
    Errr .. uhh ... sbuild в каталоге упаковки делает то же самое, что и pbuild. Извините, но -1 для этого. Исправьте и обратитесь к этому, и я удалю свой -1 – SpamapS 28 November 2012 в 01:06
  • 3
    Кроме того, «изменить что-то в chroot и сохранить его». использование случай вводит в заблуждение. Это плохая идея, так как она изменяет ваш чистый chroot, чтобы он отличался от чистого chroot. Его почти никогда не советовали. – SpamapS 28 November 2012 в 01:08
  • 4
    @SpamapS, я фактически использую pbuilder-dist --login --save-after-login, чтобы немного изменить среду сборки, потому что, например, мне нужен специальный пакет, а его источник sources.list по умолчанию не существует. Таким образом, имеет смысл настраивать среду chroot. – Alexis Wilke 25 July 2016 в 03:16
  • 5
    извините за критику вашей критики, но - «вердикт: небольшое преимущество для pbuild, меньше символов для ввода меньше символов». - Это очень глупый аргумент, не очень серьезный. Ввод 5 меньших символов не является фактором, когда мы сравниваем системы SW, очевидно, существуют гораздо более важные различия. – Tele 18 May 2017 в 05:11

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

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

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

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

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

Создайте chroot

mk-sbuild --arch=armhf quantal

vs

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

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

Загрузите исходный пакет

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

vs.

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

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

Введите chroot, ephemeral version

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

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

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

vs.

ptest quantal-armhf --save

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

Создайте пакет внутри chroot

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

vs.

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

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

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

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

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

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

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

18
ответ дан 10 August 2018 в 09:29

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

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

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

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

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

Создайте chroot

mk-sbuild --arch=armhf quantal

vs

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

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

Загрузите исходный пакет

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

vs.

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

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

Введите chroot, ephemeral version

schroot -c quantal-armhf

vs.

ptest quantal-armhf

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

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

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

vs.

ptest quantal-armhf --save

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

Создайте пакет внутри chroot

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

vs.

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

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

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

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

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

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

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

18
ответ дан 13 August 2018 в 12:58

Другие вопросы по тегам:

Похожие вопросы: