Подпись RPM при сборке пакета

 https://habr.com/ru/post/354136/

rpmbuild: условия в Requires

 Starting with rpm-4.13, RPM is able to process boolean expressions in all dependencies (Requires, Recommends, Suggests, Supplements, Enhances, Conflicts). Boolean Expressions are always enclosed with parenthesis. They are build out of “normal” dependencies: either name only or name, comparison and version description.

https://rpm.org/user_doc/boolean_dependencies.html

То есть теперь можно написать такие вещи как

Requires: (pkgA or (pkgB and pkgC))

Supplements: (foo and (lang-support-cz or lang-support-all))

и так далее. НО - это всё есть только в centos8, в 7 и ниже версии старые, в 7 например 4.11.

CentOS: чем собирать пакеты

1) классика, rpmbuild
1.5) собираем srpm и потом дособираем пакеты через mock
2) fpm. Осторожно, ruby! Умеет собирать не только под центос, но руби убивает его на корню.
3) tito
4) rpkg

Чем плох rpmbuild - он не умеет выкачивать сам пакеты (есть spectool, но он качает только готовые файлы), интеграции с гитом не умеет. Умеет в частности tito, или можно взять за пример такое.

Расширенная статистика nginx

Есть такой пакет, nginx-module-vts, даёт много полезной информации. Есть ссылка на офсайте в разделе NGINX 3rd Party Modules.
Но последний коммит был 30 июня 2018 и с тех пор автор не отвечает.

Есть другой модуль, nginx-lua-prometheus. Под debian есть инструкция через установку libnginx-mod-http-lua, но centos тут в пролёте, так что собираем первый.

CentOS7: монтируем ufs разделы

После переезда с фряхи на центос бывает необходимость получить доступ к старым данным, варианты там - zfs и ufs. Рассмотрим случай под ufs
Под центос 6 в elrepo была сборка dkms-ufs, но под 7 версию её уже нет. Увы, SRPM от 6 тоже недоступно, нужно собрать самим.

CentOS 7: собираем libtgvoip

За основу хорошо заходят 2 пакета:
http://rpmfind.net/linux/RPM/rpmfusion/free/fedora/updates/27/x86_64/l/libtgvoip-1.0.3-1.fc27.x86_64.html
http://rpmfind.net/linux/RPM/rpmfusion/free/fedora/updates/27/x86_64/l/libtgvoip-devel-1.0.3-1.fc27.x86_64.html
Также нужны mock и gyp с поддержкой cmake

mock -r epel-7-x86_64 rebuild libtgvoip-1.0.3-1.fc27.src.rpm

(тут будет момент с gyp - нужно будет также встроить свежий gyp, так что вместо epel будет своя репа c gyp, куда в том числе нужно добавить данные репы centos-sclo-rh для devtoolset)

Но всё-равно не соберётся. Вторым шагом будет или выпиливание webrtc блока (оно на c++17), или установка gcc 5. Версия 4.9 его не устроит. Ставим devtoolset-4-gcc

Но всё-равно не соберётся, потому что mock тянет штатную версию 4.8.

А также, будет ошибка

usr/include/c++/5.3.1/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

С ручной сборкой

Только тут момент: ошибка изменится на

error: ‘typeof’ was not declared in this scope

фикс: typeof отсутствует(?) в с++11, надо писать -std=gnu++11

https://github.com/kohler/click/issues/230

или (возможно?) поможет такая штука

#define typeof(x) __typeof__(x)

https://github.com/neu-rah/ArduinoMenu/issues/68

Теперь в спеке нужны изменения

pushd out/Release

+    sed -i'' -e "14i add_definitions(-std=gnu++11)" CMakeLists.txt

    %cmake .

%global _hardened_build 1

У некоторых пакетов можно встретить такое
%global _hardened_build 1

Описание есть тут
https://fedoraproject.org/wiki/Changes/Harden_All_Packages

Currently, the Packaging Guidelines allow maintainers to decide whether their packages use position-independent code (PIC). There are rules that say that a lot of packages should use PIC, but in reality a lot of packages do not use PIC even if they must. Also since a lot of packages if not all potentially process untrusted input, it makes sense for these packages to use PIC to enhance the security of Fedora. Therefore I propose to build all packages with PIC by changing RPM to use the appropriate flags by default.

rpmbuild и дополнительные опции

Есть такая интересная штука
http://rpm.org/user_doc/conditional_builds.html
используется так:
$ rpmbuild -ba newpackage.spec --with gnutls --without openssl
и дальше проверять так
%if %{with gnutls} BuildRequires: gnutls-devel %endif %if %{with openssl} BuildRequires: openssl-devel %endif

Также для работы в начале .spec файла можно вписать (как предустановленные значения)

%bcond_with gnutls

Но тут есть нюанс: то, что вписано в .spec, имеет противоположное значение! Объяснение есть например тут

https://lists.fedoraproject.org/pipermail/devel/2011-December/160357.html

rpmbuild: отключаем проверку зависимостей

Иногда собираем проект, где внутри свои либы... А при установке эти либы хочет увидеть на стандартных местах.

Отключить можно так:

1) AutoReqProv: no в спек или в ~/.rpmmacros

2) %define %__find_requires         %{nil}

или %define __find_requires         /bin/true

По аналогии можно отключить авто provides:

%__find_provides   /bin/true

или Autoprov: 0

линки:

http://rpm5.org/docs/max-rpm.html#s2-rpm-depend-autoreqprov

http://rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html

python: Собираем свой пакет из pip версии

Зачастую в пакетах лежит нужная библиотека, но отставшая от нужной версии года так на 3-4. Или вообще доступная только в pip.

Самый простой вариант это использовать библиотеку из pip. К сожалению, у pip нет "собранных" версий, поэтому на хосте тогда нужен компилятор, что многим неприемлемо для "боевых" сред. И в целом это разумно.

Хороший выход - используем ноду для сборки и собираем там virtualenv с нужными пакетами. А потом итог оборачиваем в пакет (пишем спеку). Также это может быть докер, но опять же - туда нужен компилятор... И опять возвращаемся к virtualenv. Впрочем, для простых либ и единообразной среды достаточно скопировать нужные файлы в SOURCES и раскидать их по местам установщиком пакета, более сложные либы лучше пакетировать раздельно. Если уже есть такая же старая либа --  всё просто, качаем .src.rpm, правим .spec под новую версию, подкладываем архив с новыми исходниками, собираем.

А может быть, что за основу взять нечего... Тогда можно взять например python-pika, скопировать его spec и начать правки.

Нужно скачать архив нужной версии, для примера сделаем пакет для couchbase. Работаем от обычного пользователя, который будет заниматься сборкой

rpmbuild: *** ERROR: No build ID note found in ...

Лечение:
1) добавить в сборку node-id
--buil-id
Если не помогло:
2) отключить сборку debuginfo
a) %global _missing_build_ids_terminate_build 0
б) %global debug_package %{nil}
в) попробовать удалить "проблемные" файлы