Development for Linux
Comments 11
0
Код программы, соответствующий исправленной ветке, можно будет использовать при сборке RPM

Не стоит! Сделайте в своей ветке
git format-patch -N
, где N — кол-во ваших коммитов, затем все патчи приложите к пакету:

Patch1: 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
Добавил в статью информацию о патчах, описание ещё нескольких опций спек-файла и несколько ссылок.
0

Неплохо. Но:
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 и могут быть файлы от разных пакетов с одинаковым названием.

0
Спасибо, всё исправил. Добавил информацию о том, что нужно очищать папку SOURCES перед сборкой нового проекта (или новой версии).
0
Можно при вызове rpmbuild задавать свою %_sourcedir или %_topdir, пример: github.com/ONLYOFFICE/desktop-apps/blob/master/win-linux/package/linux/Makefile#L208
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 как раз собирает в чистом чруте, многим кажется удобным.
0
В любом случае большое спасибо за статью. Буду на нее давать ссылку новичкам.
0
Неделю назад начал изучать сборку RPM пакетов, причем именно на Rosa Linux, и ваша статья как раз кстати. Спасибо :)
0

Думаю, это зависит от ситуации и от предпочтений. Если надо собрать пакеты сразу для нескольких операционных систем или дистрибутивов, то fpm — хорошая штука. Но, если нужен только пакет RPM, судя по этой статье, создание спек-файла может быть не намного тяжелее (или даже не тяжелее). Тем более когда немного знаешь как это делать. И пакет RPM, собранный для Rosa Linux, может немного отличаться от такого же пакета для OpenSuse или RedHat.

Only those users with full accounts are able to leave comments., please.