Comments 31
А не проще rpmbuild -ba для SPEC и rpmbuild --rebuld для SRPM?
Помимо этого еще нужно настроить GPG подпись и использовать --sign или позже их подписывать, если собираетесь создавать репозиторий.
Помимо этого еще нужно настроить GPG подпись и использовать --sign или позже их подписывать, если собираетесь создавать репозиторий.
rpmbuild -ba начнёт компилировать исходники, что за нас делает mock. Это будет просто двойная работа. Тут вся прелесть именно в mock и его оптимизации рпмки под конкретные депендсы дистра.
Если использовать репозитории исключительно для своих целей, то подписывать и не обязательно. при добавлении кастомного репо достаточно указать gpgcheck=0
Если использовать репозитории исключительно для своих целей, то подписывать и не обязательно. при добавлении кастомного репо достаточно указать gpgcheck=0
> rpmbuild -ba начнёт компилировать исходники, что за нас делает mock. Это будет просто двойная работа. Тут вся прелесть именно в mock и его оптимизации рпмки под конкретные депендсы дистра.
> Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot.
Поясните, пожалуйста, как он оптимизирует RPM и что за конкретные «депенденсы дистра»?
> Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot.
Поясните, пожалуйста, как он оптимизирует RPM и что за конкретные «депенденсы дистра»?
>One of the nice things about using mock is that it allows you to build for different target archs and operating systems without having to jump around to multiple systems. This means that on a x86_64 machine running FC4 it is possible to build both i386 and x86_64 packages for Redhat (Linux and Enterprise Linux), Fedora Core, CentOS, etc. ©
Возможно не верно выразил мысль.
Возможно не верно выразил мысль.
rpmbuild --target= — кросс-компиляция без mock.
При этом всё соберётся под glibc/остальные библиотеки из sysroot кросс-компилятора.
А если нужно собрать для другого дистрибутива но на этой же архитектуре?
Будете заводить специальный кросс-компилятор? Или дадите mock'у установить родное окружение для сборки в chroot?
А если нужно собрать для другого дистрибутива но на этой же архитектуре?
Будете заводить специальный кросс-компилятор? Или дадите mock'у установить родное окружение для сборки в chroot?
Не понимаю что значит «другого дистрибутива». Пакеты от Fedora свободно ставятся в CentOS/RHEL. Ну а под Debian собирать пакеты в CentOS — это уже маразмом попахивает.
Да и билдсервисы для разных платформ я предпочитаю организовывать в виртуальных машинах.
Да и билдсервисы для разных платформ я предпочитаю организовывать в виртуальных машинах.
Хорошо, попробуйте собрать на Fedora-13 пакеты для Fedora-8.
UFO just landed and posted this here
Речь в этой ветке — о сборке командой rpmbuild.
И в чём отличие приведённого по ссылке от mock кроме названия?
И в чём отличие приведённого по ссылке от mock кроме названия?
UFO just landed and posted this here
Ок. Читаем по вашей ссылке:
Напомню, что mock устанавливает (или разворачивает из кеша) в chroot стандартный набор пакетов, к которым доустанавливает BuildRequires собираемого пакета. После чего выполняет сборку в этом chroot.
В чём, вы говорите, архитектурные различия?
- Сейчас сборка проводится в chroot в конкретную систему.
- Перед сборкой пакета нужно установить все необходимые для сборки пакеты. Существует команда получения списка необходимых для сборки пакетов (rpmgp -l). Далее штатным средством системы (apt-get, yum) в неё устанавливаются эти пакеты.
Напомню, что mock устанавливает (или разворачивает из кеша) в chroot стандартный набор пакетов, к которым доустанавливает BuildRequires собираемого пакета. После чего выполняет сборку в этом chroot.
В чём, вы говорите, архитектурные различия?
Ставите Fedora 8 в виртуальную среду и собираете пока не надоест.
«Конкретные депендсы дистра» это наверно конкретные версии gcc/glibc/..., которые не принято указывать в спеке.
Был момент, когда понадобилось собрать rpm-ку из набора откомпиленых файлов (там нестандартная система сборки и установки, ну и вообще. И если с дебианом всё просто (натравливается на дерево данных пакета dpkg -b и он просто всё пакует в архив, на забыв положить туда control и скрипты), то с rpm пришлось укуриться мануалами и родить вот такую конструкцию:
rpmbuild -ba wtf.spec --buildroot `pwd`/tree/ --define='%_topdir rpmbuild'
ИЧСХ, пакет собирается без всяких рутовых прав (fakeroot+chown -R).
rpmbuild -ba wtf.spec --buildroot `pwd`/tree/ --define='%_topdir rpmbuild'
ИЧСХ, пакет собирается без всяких рутовых прав (fakeroot+chown -R).
Мне приходилось добавлять специфические пакеты не идущие в изначальном chroot, делается это в строке config_opts['chroot_setup_cmd'].
а разве не для этого предусмотрено
BuildRequires:
UFO just landed and posted this here
За скрипт спасибо. Иногда приходится собирать странные вещи не входящие в стандартные репозитории.
UFO just landed and posted this here
>Еще, у вас в посте ошибка в команде
Эту часть команды я честно скомуниздил с wiki.centos.org/HowTos/SetupRpmBuildEnvironment так что уж как есть.
А на тему подписей — увы, все пакеты я собирал для личного использования и проще было проигнорить ключи, чем искать как это делается по феншую.
Эту часть команды я честно скомуниздил с wiki.centos.org/HowTos/SetupRpmBuildEnvironment так что уж как есть.
А на тему подписей — увы, все пакеты я собирал для личного использования и проще было проигнорить ключи, чем искать как это делается по феншую.
Если необходимо собирать пакеты под различные платформы (не только rhel/centos), то есть отличный продукт Opensuse build service. Можно собирать пакеты под разные архитектуры (не только под x86/64) один пакет можно собрать под разные дистрибутивы (centos/rhel,fedora,mandriva,opensuse/sles,debian/ubuntu). В случае последних двух общими с rpm дистрами могут быть только сорцы. Если инфраструктура проекта простая можно обойтись build.opensuse.org. Для сложных проектов(много пакетов, сложные настройки прав доступа, специфические дистрибутивы итд) можно поставить локальную копию. Преимущества: не требуется держать кучу машин для разных дистрибутивов, можно на одной машине собирать под разные архитектуры(можно настроить таким образом, чтобы воркеры запускали xen/kvm виртуалки и билдили в них), можно компоновать пакеты различным образом, создавая разные репозитории с разными версиями одного и того же ПО (напр. в одном репозитории модуль собран с продакшн ядром, а в другом этот же модуль собран с тестовым ядром ).
Sign up to leave a comment.
RPM-репозиторий своими руками