Изменения в mock 1.2

Появилось дополнение к новости о выходе версии 1.2 утилиты для сборки RPM, mock. Michael Šimáček решил поподробнее рассказать о нововведениях в этой версии. которых больше, чем было анонсировано. И действительно, список новинок довольно значителен:

  • Уже упомянутый плугин для LVM. Это изменения для больших билд-ферм, которое будет использовать фичи LVM по созданию снапшотов. Общая пакетная база, из которой собираются rootfs для сборки, как правило, довольно значительна. Поэтому LVM должен сильно экономить время на перегенерацию roots при его использовании. Раньше мы использовали тарболы, которые распаковывались в chroot.
  • Улучшение производительности с помощью nosync при перегенерации Yum DB при сборке rootfs. В случае создания rootfs особая надежность на случай аварии не нужна, поэтому нет нужды вызывать большое количество раз fsync (man 2 fsync), что ускорит сборку пакетов.
  • Поддержка dnf. Мы уже используем dnf в быту - работает надежно, хотя порой иначе, чем yum, что замечали и наши коллеги. Пока фича считается экпериментальной.
  • Улучшенный режим журналирования. Теперь mock печатает в консоли и вывод Yum/DNF и rpmbuild.
  • Меньшее количество блокирующих операций. Некоторые операции над rootfs теперь поддерживают множественный доступ, например shell-доступ к ней, прямо в процессе сборки.
  • Теперь mock может выполнять дополнительные команды Yum/DNF, например mock --pm-cmd clean metadata-expire.
  • В процессе сборки rootfs можно выполнять команды --enablerepo и --disablerepo пакетного менеджера.
  • Долгожданная команда short-circuit, позволяющая проходить заново обвалившиеся стадии без запуска с самого начала.
  • Возможность передачи дополнительных аргументов в rpmbuild. Например для выбора алгоритма сжатия в финальном пакете.
  • Теперь можно задавать свои пути к утилитам rpm, rpmbuild, yum, yum-builddep, dnf. Таким образом можно легко подменять их своими версиями, без необходимости изменять system-wide копии.
  • Автоматическая инициализация и улучшенная очистка после завершения.
  • Поддержка Python 3.
  • Малоизвестная фича --unique-ext. Она позволяет запускать в параллель несколько сборок одного и того же пакета, с тем же названием. Напрямую это сделать нельзя, т.к. сборки будут использовать одну и ту же директорию для chroot, а благодаря этому ключу к названию добавится указанный суффикс, и конфликта не будет.


Конечно, пока наша инфраструктура неидеальна, но судя по таким новостям, мы потихоньку движемся в верном направлении!