algri14⇓ пишет:alex_q_2000, для чего эта штуковина нужна
***Все персонажи и диалоги вымышлены...
algri14, на мысль о PatchCreator-е натолкнул gaurii. Просто я подумал, а стоит ли "опакечивать" программу из-за пары бинарников? По уму, конечно надо. Но это же лишняя работа, а двигателем прогресса является лень... ))
Преамбула:
--------------------------------------------------------------------
На фоне бороздящих космос ракет, rpmbuild выглядит довольно уныло. Если всё максимально упростить, то результатом его работы является сжатие всех файлов программы в единый архив с расширением *.rpm. Устанавливая пакет, менеджер разматывает этот *.rpm и распихивает файлы, которые у него внутри по нужным местам.
Например:
--------------------------------------------------------------------
/usr/share/папка-программы
/usr/share/icons/иконка-программы
/usr/share/applications/ярлык-программы.desktop
/usr/bin/пусковой-файл
/другие/папки/и/файлы ...
Чтобы работать с rpmbuild нужно понимать, что от чего зависит, что на что смотрит, откуда цепляет настройки, куда сохраняет с учетом прав и многое-многое другое. Вся последовательность шагов по созданию пакета пишется в некий "сценарий" - файл.spec (спек), сверяясь с которым rpmbuild на конечном этапе анализирует зависимости и собирает пакет.rpm. SPEC - это рукописный файл иногда километровой длины, набитый под завязку разной хернёй. Вся простыня кода разбита на секции, каждая из которых предназначена для описания действий по созданию/установке/удалению создаваемого пакета.rpm. Примеры секций: %global, %setup, %build, %install, %clean, %files, %postun и др. В спЕках пути к стандартным директориям Linux принято описывать в виде алиасов/псевдонимов/шаблонов (назовите как угодно). Например: %{buildroot}%{_datadir}/icons или там %{_bindir} или %{_datadir}/applications, ибо разница архитектур. Если валидный SPEC успешно создан, товарищу можно сразу выдавать медаль героя соц. труда и отправлять досрочно на пенсию. ))
PatchCreator, как генератор патчей (пример)
--------------------------------------------------------------------
TopE исправил ошибку в исходнике некой программы и получил исправленный бинарник + кучку библиотек + ещё иконку свою прилепил. На его компе исправленные файлы уже находятся в нужных папках и программа работает. Ему звонит ingvaro и говорит: "Здорова, TopE! Как жизнь? Слушай, у тебя тоже эта хрень не запускается?" Тот отвечает: "Да, но я уже пофиксил." ingvaro: "Мир тебе, чувак! Зашли патч в оркестр..." TopE запускает PatchCreator и делает снимок (патч, sfx-архив) файлов со своей системы. Отправляет результат собеседнику. ingvaro у себя запускает полученный патч и при встрече ставит бутылку пива TopE. Мир, дружба, жвачка.
PatchCreator, если рассматривать как инсталлятор (перспектива)...
--------------------------------------------------------------------
Оставим дзЭн для программеров/мейнтайнеров/девелоперов. Единственное, что мы уяснили железно, - у нас уже есть готовые бинарник, ярлык, иконка. Чтобы автоматически раскидать их в нужные папки системы, мы создаём sfx-архив. Для этого сначала вручную раскидываем всё это добро в папки рабочей системы и собираем с учетом путей в архив с помощью PatchCreator-а, т.е. делаем "снимок" нужных объектов, уже расположенных в нужных местах. Затем распространяем его как обычную программу Linux, только ставится она не из пакета.rpm, а из патча.run. Деинсталляция - операция обратная инсталляции. Поскольку sfx-патч.run создавался с использованием списка добавления в архив, нужно выполнить обратную операцию удаления по тому же списку (rm ...files.lst в скрипте). Эту возможность я не предусматривал, поскольку надобности нет. Да и речь в этой теме идёт о правке исходников + распространении "прививок" в виде автораспаковщика исправленных бинарников.
p.s. Извиняюсь за "растянутый" ответ. У меня опять открылся родник досужих помыслов, словоблудия и графомании. 
, в августе или сентябре иду в отпуск, создам тему - Как собрать 
Иначе ~/Folder это /root/Folder 
