Комментарии 17
Oh god.
У пакета должны быть Source* и Requires/BuildRequires теги, и секция %prep, тогда не надо ничего распаковывать и собирать в билдруте руками.
Собирать лучше через mock (и ваш спек там не соберется), особенно если нужно покрыть несколько архитектур.
В секции %files лучше использовать макросы для указания целевых директорий.
В теге Release стоит использовать макрос {?dist} вместо захардкоженного.
Прогоните ваш спек через rpmlint хотя-бы.
А пока я оставлю здесь fedoraproject.org/wiki/How_to_create_an_RPM_package
Хорошая стартовая точка для нового спек-файла — rpmdev-newspec (хотя там тоже есть пара устаревших вещей)
У пакета должны быть Source* и Requires/BuildRequires теги, и секция %prep, тогда не надо ничего распаковывать и собирать в билдруте руками.
Собирать лучше через mock (и ваш спек там не соберется), особенно если нужно покрыть несколько архитектур.
В секции %files лучше использовать макросы для указания целевых директорий.
В теге Release стоит использовать макрос {?dist} вместо захардкоженного.
Прогоните ваш спек через rpmlint хотя-бы.
А пока я оставлю здесь fedoraproject.org/wiki/How_to_create_an_RPM_package
Хорошая стартовая точка для нового спек-файла — rpmdev-newspec (хотя там тоже есть пара устаревших вещей)
Спасибо. А что нужно писать в поле Requires для библиотеки? Ведь зависимости будут автоматически прописаны в пакете.
Насколько я помню, автоматически будут прописаны только очевидные прямые зависимости (например, найденные через ldd). Соответственно все остальное (либы, которые грузятся через dlopen, например) надо указывать вручную.
Или же у вас какое-нибудь веб-приложение (ownclowd, например), которому нужен веб-сервер (там чуть сложнее, правда, с подпакетами).
Или же у вас какое-нибудь веб-приложение (ownclowd, например), которому нужен веб-сервер (там чуть сложнее, правда, с подпакетами).
Когда будете собирать через mock — будут сыпаться постоянно ошибки из-за неустановленных зависимостей. Их и нужно будет прописать в BuildRequires. В Requires нужно прописывать пакеты, которые нужны для работы. Но в вашем случае уже есть готовый пакет со спеком: mirror.yandex.ru/fedora/linux/development/rawhide/source/SRPMS/z/ Да и вообще в большинстве случаев в котле федоры есть уже опакетированные программы.
посмотрел по Вашей ссылке и нашел упоминание mock в этой команде:
usermod -a -G mock makerpm
Вы это имели ввиду написав «Собирать лучше через mock»?
(а тема и обсуждение очень как вовремя, спасибо)
usermod -a -G mock makerpm
Вы это имели ввиду написав «Собирать лучше через mock»?
(а тема и обсуждение очень как вовремя, спасибо)
Нет-нет. mock это такая штука, которая создает почти виртуалку, ставит туда базовый набор пакетов и зависимости, прописанные в спеке и пытается все это собрать.
fedoraproject.org/wiki/Using_Mock_to_test_package_builds
fedoraproject.org/wiki/Using_Mock_to_test_package_builds
на примере Red Hat Enterprise Linux 6
В RHEL6 не надо прописывать ничего в .rpmmacros чтобы собиралось в ~/rpmbuild
Создавать директории вручную тоже совершенно необязательно, они созаются при установке первого src.rpm в систему, плюс у rpmbuild есть специаьный ключ для создания дерева каталогов
Лучше использовать mock/koji
Есть такая замечательная штука как rpmlint, которая будет сильно ругаться на Ваш пакет.
В Release лучше использовать макрсо, вместо хардкордного rhel6
/usr/lib64/libzmq.so.3— ваш пакет только для x86_64? Почему не использовать %{_libdir} для универсальности?
/usr/include
/usr/share
Никому этого не показывайте :) Почему zeromq должен быть владельцем этих директорий? Вы хотите чтобы директории были удалены при удалении пакета?
Почитайте RPM Guide и Fedora Packaging Guidelines, правда, откроете для себя много нового и полезного.
А как же сборка пакетов из исходников от других версий ОС?
Чаще возникает ситуация когда пакет есть, но устарел и его свежая версия есть для следующей версии дистрибутива.
тогда приходит на помощь rpmbuild --rebuild somepackage.src.rpm
Да и, говоря сборке пакетов, следует упомянуть Fascist build policy с которым можно столкнуться.
Чаще возникает ситуация когда пакет есть, но устарел и его свежая версия есть для следующей версии дистрибутива.
тогда приходит на помощь rpmbuild --rebuild somepackage.src.rpm
Да и, говоря сборке пакетов, следует упомянуть Fascist build policy с которым можно столкнуться.
Посмотреть, какие файлы предоставляет пакет, можно и не распаковывая его, с помощью опции «f»:
$ rpm -qfp package.rpm
С помощью опции -l (маленькая латинская эль). С помощью -f можно найти пакет владеющий указанным файлом.
Есть хороший пример spec фаила с объяснениями объяснениями
А нет варианта, как в debian-based, вообще не возиться ни с какими спец. файлами а просто сказать «make checkinstall» вместо «make install»?
Вот последний чем и радует, что минимально рабочий пакет, который будет нормально ставиться и удаляться можно вот так просто и сделать.
Отложим разные преимущества «тонкого тюнинга», речь не о них. Именно максимально прямолинейный и «влобный» способ — есть такой для rpm?
(а, ну да, если билд управляется cmake, то вроде очевидно. А если просто автотулзы?)
Вот последний чем и радует, что минимально рабочий пакет, который будет нормально ставиться и удаляться можно вот так просто и сделать.
Отложим разные преимущества «тонкого тюнинга», речь не о них. Именно максимально прямолинейный и «влобный» способ — есть такой для rpm?
(а, ну да, если билд управляется cmake, то вроде очевидно. А если просто автотулзы?)
checkinstall работает и для rpm, но, насколько я знаю, он сразу устанавливает пакет. А речь о том, чтобы а) собрать пакет один раз, который потом будет использоваться всей командой, и б) вынести заголовочные файлы в devel-пакет, т.к. они не нужны будут там, где будет запускаться приложение. Хотя, может, я недостаточно разобрался в checkinstall.
У rpm есть все средства собрать пакет самостоятельно. Зачем закатывать солнце в ручную не понятно. Это упрощает задачу до сделать spec файл и положить исходники и патчи.
Зачем это всё, если есть fpm?
Напишите пост, как им пользоваться ;)
Он простой, как три копейки. Например собрать собственный rpm-пакет из папки можно так(пример из оф. вики):
fpm -s dir -t rpm -n «slashbin» -v 1.0 /bin /sbin
Эта команда пакетирует все файлы из директорий /bin и /sbin в rpm-пакет slashbin версии 1.0.
В fpm нет огромных манов, это удобный инструмент от того, кто устал генерить валидные spec-файлы и всё, что там еще надо, для таких же уставших.
Если вы не мейнтейнер каких-то пакетов — то вся это возня вам практически наверняка не нужна.
fpm -s dir -t rpm -n «slashbin» -v 1.0 /bin /sbin
Эта команда пакетирует все файлы из директорий /bin и /sbin в rpm-пакет slashbin версии 1.0.
В fpm нет огромных манов, это удобный инструмент от того, кто устал генерить валидные spec-файлы и всё, что там еще надо, для таких же уставших.
Если вы не мейнтейнер каких-то пакетов — то вся это возня вам практически наверняка не нужна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сборка пакетов библиотек для rpm-based дистрибутивов Linux