Comments 11
Код программы, соответствующий исправленной ветке, можно будет использовать при сборке RPM
Не стоит! Сделайте в своей ветке
git format-patch -NPatch1: 0001-xxx.patch
Patch2: 0002-xxx.patch
<...>
%prep
%setup
%apply_patchesЭто позволит сразу четко видеть, какие правки были сделаны относительно апстрима.
Source0: https://github.com/ваше-имя/имя-проекта/archive/имя-ветки-с-исправлениями.zipТак тоже не надо делать. Если хотите все же прямо из git собирать, то укажите дерево конкретного коммита, чтобы, когда вы сделаете новые коммиты, используемые при сборке исходники не изменились. Пример: abf.io/import/realmd/blob/890302de0d7d9518781aee834afd325ce5c3e046/realmd.spec
Неплохо. Но:
1) "~/rpmbuils/SOURCES" — здесь опечатка
2) ни разу не встречал патчей с наименованием пакет-версия-rosa-описание.patch. Обычно без "rosa"
3) включать название и версию пакета в имя патча — я считаю, очень контрпродуктивно. Народ тратит время и силы на "красивое" наименование патчей, а сил написать описание патча, что и зачем он делает, — не остается. При обновлении версии из-за переименований файла часто едет история git.
В списке патчей эти лишние буквы мешают сразу видеть суть патча по названию файла, особенно, когда такое длинное название куда-нибудь не влезает по ширине и обрезается середина имени файла. Пример: https://abf.io/import/systemd/tree/rosa2016.1 На какой бы черт может понадобиться назвать всю кучу патчей вместо 000N-суть-патча.patch systemd-230-rosa-000N-суть-патча.patch?
Единственное удобство от такой схемы, которое смог придумать, — это когда вместо работы с git с файлами пакетами в отдельной директории все от множества пакетов свалено в ~/rpmbuild/SOURCES и могут быть файлы от разных пакетов с одинаковым названием.
SOURCES перед сборкой нового проекта (или новой версии).abf-console-client (https://abf.io/soft/abf-console-client) командой abf rpmbuild примерно это и делает: создает в /tmp/ отдельную временную папку, внутри которой создается структура, аналогичная ~/rpmbuild/. rpmbb/rpmbs из etersoft-build-utils (https://packages.altlinux.org/ru/sisyphus/srpms/etersoft-build-utils) делают похожее, но еще дополнительно работают с git. Плюс dpkg в том, что можно легко хранить спеки с исходниками вместе и спокойно собирать пакет из кода, когда как в RPM нельзя просто так так сделать и разные обвязки над RPM пытаются решить эту проблему, у gear+etersoft-build-utils это неплохо получается. Но зато в RPM более упорядоченная структура.
Я для сборок пакетов использую rootfs, запускаемую в контейнере: wiki.rosalab.ru/ru/index.php/Образ_rootfs
При сборке локально сборочное окружение грязное, в сборочнице с чистым окружением результат может быть другим, например, потому что части сборочных зависимостей не будет. mock-urpm как раз собирает в чистом чруте, многим кажется удобным.
Думаю, это зависит от ситуации и от предпочтений. Если надо собрать пакеты сразу для нескольких операционных систем или дистрибутивов, то fpm — хорошая штука. Но, если нужен только пакет RPM, судя по этой статье, создание спек-файла может быть не намного тяжелее (или даже не тяжелее). Тем более когда немного знаешь как это делать. И пакет RPM, собранный для Rosa Linux, может немного отличаться от такого же пакета для OpenSuse или RedHat.
Построение пакета RPM для Rosa Linux на практике