1 (2019-06-02 10:32:50 отредактировано alex_q_2000)

RPMCreator v1.2-1 UPD: 02.06.2019
-------------------------------------------------------
Программа для сборки пакетов RPM из файлов и папок. Использует rpmbuild. Сборка пакета RPM проходит через создание простейшего проекта, который можно сохранить/загрузить, что позволяет сделать процесс сборки поэтапным. Рабочий каталог: ~/rpmbuild.

http://images.vfl.ru/ii/1553234606/84738759/25868493_s.png  http://images.vfl.ru/ii/1553234607/f9e9dc11/25868494_s.png

Изменения:

Spoiler

1.2-1 + фильтр "Any files (*)" - загрузка из любого файла
1.2-0 + кнопки перемещения записей списка файлов/папок пакета, адаптация к Mageia-7
1.1-9 + turn off the brp-python-bytecompile script: %define __brp_python_bytecompile %{nil}
1.1-7 + распаковщик пакетов *.deb и *.rpm (p7zip)
1.1-6 + контроль абсолютных путей; списки в repack.txt
1.1-4 + общая форма добавления файлов и папок + симлинки
1.1-3 + каталог настроек и временных файлов: ~/.RPMCreator
1.1-2 + disable Java: %define __jar_repack %{nil}
1.1-1
+ исправлены атрибуты: %defattr (-,root,root,755)
+ шаблоны %post, %postun
+ пакет createrepo
1.0-9 + подписывание пакетов (требуется создать ключи gpg и ~/.rpmmacros)
1.0-8
+ изменён About
+ предустановочные и постустановочные секции пишутся в spec избирательно
+ генерация doc-файла repack.txt с указанием метода, средств разработки, и т.п
+ дополнительная проверка очистки ~/rpmbuild/BUILD/PACKAGE ~/rpmbuild/BUILDROOT
1.0-7 + Решена проблема с пробелами в путях к файлам в spec
1.0-4 + Метки каталогов при создании списка файлов из rpm-пакета
1.0-3 + Отключение проверок AutoReq, AutoProv, AutoReqProv и метка-индикатор ожидания архивации
1.0-2 + Group (список), BuildArch (в spec), BuildRequires, License (список)
1.0-0 - Концепция изменилась. Теперь RPMCreator работает напрямую с rpmbuild (rpm, src, spec)
0.9-7 + Кнопка "RPM" - загрузка списка файлов из rpm -ql имя_пакета
0.9-6 + Пакеты ruby-RubyGems ruby-devel libffi-devel rpm-build gcc make - зависимости + "gem install --no-ri --no-rdoc fpm" (%post)
0.9-5 + Предустановочные и постустановочные сценарии, Вендор и тип Лицензии
0.9-4 + Сведения о rpm-пакете: Мейнтейнер и URL сайта
0.9-3 + Возможность сборки мета-пакета (пустой rpm с зависимостями)
0.9-2 + Управление релизом пакета. Например: 2.mga6
0.8 + Многострочные редакторы команд "После установки" и "После удаления"
0.7 + Терминал sakura - зависимость rpm
0.6 + Косметические правки
0.5 + Совместимость проектов *.lst и *.prj. Взаимное использование списков собираемых файлов и папок PatchCreator <> RPMCreator
0.4
+ Изменена схема сохранения проекта (запросы/подтверждения)
+ Переименование ключа ARCH/NOARCH при сохранении
0.3b + Команды после установки и удаления rpm через ";". Например: mkdir /123; echo "Create a directory"; ...
0.3a + "noarch" для всех архитектур

PatchCreator v0.8-0 UPD: 02.06.2019
-------------------------------------------------------
Программа для снятия снапшотов файлов/папок или объектов, входящих в состав определённого пакета RPM. Результатом работы программы является SFX-архив, который удобно разматывать на любом компе одним кликом без дополнительных ключей. В проекте использован код MakeSelf (Stephane Peter). Программой удобно создавать авто-патчи.

http://images.vfl.ru/ii/1529774791/f8467683/22223294_s.png  http://images.vfl.ru/ii/1529593518/31b7f70b/22199362_s.png

Изменения:

Spoiler

0.8-0 + фильтр "Any files (*)" - загрузка из любого файла
0.7-9 + каталог настроек и временных файлов: ~/.PatchCreator
0.7-6 + Метки каталогов при создании списка файлов из rpm-пакета
0.7.5 + Флаг сохранения при изменении списка из rpm -ql имя_пакета
0.7.4 + Косметические правки
0.7-3 + Вывод подсказок
0.7-2 + Вывод сообщений сохранения списков файлов и папок
0.7 + Терминал sakura - зависимость rpm
0.6 + Косметические правки
0.5 + Совместимость проектов *.lst и *.prj. Взаимное использование списков собираемых файлов и папок PatchCreator <> RPMCreator
0.4 + Переработан формат загрузки/сохранения списка *.lst по аналогии с RPMCreator+GUI
       + Включается имя патча и папка назначения (файл *.lst - теперь проект; старый формат не поддерживается)

Интерфейс обоих творений интуитивно понятен и дополнительного описания не требует. Софт распространяется свободно с исходным кодом на Lazarus-1.8.4.

RPM-пакеты PatchCreator и RPMCreator лежат здесь...

Полезные статьи:
-------------------------------------------------------
Как создать самораспаковывающийся архив или инсталлятор в Linux
Gem глазами потребителя
Описание ключей FPM (Effing Package Management)

Смежная тема - "Плюшевый репозиторий"

2 (2018-06-27 21:47:02 отредактировано alex_q_2000)

Ручная сборка пакета RPM из файлов и папок на примере программы bbcolor (WYSIWYG-редактор BB-кода, x86_64)

Исходные данные:
--------------------------------------------------------------------------
Архив bbcolor-1.tar.gz с нужными файлами (бинарник, иконка, ярлык и др) и готовый пакет bbcolor-1.9-1.x86_64.rpm, собранный FPM

Установка FPM в Mageia:
--------------------------------------------------------------------------
urpmi --auto ruby-devel libffi-devel rpm-build rubygems gcc make
gem install --no-ri --no-rdoc fpm

Распихиваем нужные файлы по нужным местам:
--------------------------------------------------------------------------
/usr/bin/bbcolor - это скрипт запуска основного файла программы
Содержимое /usr/bin/bbcolor:

Spoiler
#!/bin/sh
exec /usr/share/bbcolor/mrcbbcolor #Это запуск основного файла программы

/usr/share/bbcolor - это рабочая папка самой программы; нужно создать
/usr/share/bbcolor/mrcbbcolor - это исполняемый файл самой программы
/usr/share/bbcolor/lclstrconsts.po - это языковой файл eng, нужен для mrcbbcolor
/usr/share/bbcolor/lclstrconsts.ru.po - это языковой файл rus, нужен для mrcbbcolor
/usr/share/icons/bbcolor.png - это иконка программы bbcolor (размер 128х128)

/usr/share/applications/bbcolor.desktop - это ярлык программы bbcolor
Содержимое файла /usr/share/applications/bbcolor.desktop:

Spoiler
[Desktop Entry]
Name=BBColor
Name[ru]=BBColor
Comment=BB-Code editor - это всплывающая подсказка на английском
Comment[ru]=Редактор BB-кода - это всплывающая подсказка на русском
Icon=bbcolor - искать иконку /usr/share/icons/bbcolor.png
Exec=bbcolor - исполнять пусковой скрипт /usr/bin/bbcolor
Type=Application - это приложение
Category=Utility - отобразить этот ярлык в системном меню "Стандартные-Утилиты"
Terminal=false - не использовать запуск в терминале

Собираем пакет RPM с помощью программы FPM:
--------------------------------------------------------------------------
Перед сборкой проверили, что все файлы на своих местах, программа запускается из системного меню и из терминала (bbcolor)

fpm --verbose -s dir -t rpm -n "bbcolor" -v 1.9 /usr/share/bbcolor /usr/bin/bbcolor /usr/share/icons/bbcolor.png /usr/share/applications/bbcolor.desktop /usr/share/bbcolor/lclstrconsts.ru.po /usr/share/bbcolor/lclstrconsts.po

Результат:
--------------------------------------------------------------------------
В текущей директории получаем пакет: bbcolor-1.9-1.x86_64.rpm

3 (2018-06-29 10:58:31 отредактировано alex_q_2000)

AVOTIŅI⇓ пишет:

Фигня какая-то получается - файлы ставятся в мой личный профиль. А чтобы они падали в системные папки, их надо будет туда ручками расставить и потом собрать пакет
вот результат эксперимента https://cloud.mail.ru/public/NEAU/U3GUX45Hd

Проект vacuum - Редактор Video (наверное)
------------------------------------------------------------
Для установки программы, состоящей из произвольных файлов/каталогов, сначала нужно создать/раскидать нужные файлы/каталоги этой программы по нужным местам системы и доустановить нужные зависимости. Собирать пакет следует только при условии, что вы уже запустили эту программу с ярлыка в системном меню.

В наличии у нас имеется архив spatial-media-master.zip, который содержит папку программы spatial-media-master, где сама программа gui.py - это скрипт на питоне. Имеется так же зависимость этой программы от пакета tkinter, который представляет собой графическую библиотеку, без которой на экране мы ничего не увидим. big_smile

Поскольку графическая библиотека tkinter оформлена в виде зависимости, а основной файл программы - это скрипт, то явная привязка к выводу графики отсутствует. Значит пакет оформим в виде noarch.rpm, т.е. мы планируем забить болт на архитектуру. В результате пакет будет подходить и для i686 и для x86_64.

1. Я раскидал файлы и папки программы vacuum следующим образом:
/usr/share/spatial-media-master - это папка из архива spatial-media-master.zip
/usr/bin/vacuum - пусковой скрипт основного файла программы (gui.py). Вот его содержимое:

Spoiler

#!/bin/sh
python /usr/share/spatial-media-master/spatialmedia/gui.py

/usr/share/icons/vacuum.png - это иконка программы
/usr/share/applications/vacuum.desktop - это ярлык программы. Его содержимое:

Spoiler

[Desktop Entry]
Name=Vacuum
Name[ru]=Vacuum
Comment=Video editor
Comment[ru]=Редактор видео
Icon=vacuum
Exec=vacuum
Type=Application
Categories=Utility
Terminal=false

В системном меню "Утилиты" должен появиться голубой круглый значок Vacuum. Проверяем, что программа запускается.

2. Собираем пакет из всего, что мы тут "нараспихивали"...
Для этого запускаем RPMCreator v0.3b (если версия ниже - обязательно обновитесь) и загружаем в него проект vacuum.prj. Указываем "Папку назначения" (куда выгрузить готовый пакет) и жмём кнопку "Собрать RPM-пакет". Получаем пакет vacuum-0.2-1.noarch.rpm. Наш пакет подходит для обеих архитектур и подтягивает зависимость tkinter, всё как заказывали.

Этот пакет я собрал в Mageia-5.1 i586 (на виртуалке). Но он работает везде. Вы можете его пересобрать, изменить и т.д.

Содержимое архива vacuum-project.tar.gz:
------------------------------------------------------------
1. Для сборки пакета я использовал 2 программы: PatchCreator+GUI и RPMCreator+GUI. Первой я создал самораспаковывающийся (sfx) архив vacuum.run. Он содержит снапшот программы vacuum и при запуске под root у Вас на компе (su, пароль), автоматически размотает файлы и папки vacuum по нужным местам системы. vacuum.lst - это список файлов и папок снапшота для PatchCreator+GUI
2. vacuum.prj - это файл проекта для загрузки в RPMCreator+GUI v0.3b (если версия ниже - обязательно обновитесь).
3. Готовый пакет vacuum-0.2-1.noarch.rpm для установки в систему

Здесь vacuum-project.tar.gz...

http://images.vfl.ru/ii/1530254195/6d0032c7/22291887_s.png

4 (2018-06-23 21:31:48 отредактировано alex_q_2000)

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. Извиняюсь за "растянутый" ответ. У меня опять открылся родник досужих помыслов, словоблудия и графомании. big_smile

Спасибо сказали: algri141

5

alex_q_2000 пишет:
algri14⇓ пишет:

alex_q_2000, для чего эта штуковина нужна

algri14, на мысль о PatchCreator-е натолкнул gaurii. Просто я подумал, а стоит ли "опакечивать" программу из-за пары бинарников? По уму, конечно надо. Но это же лишняя работа, а двигателем прогресса является лень... ))

Мне очень жаль, что мой пост каким-то образом послужил источником этой идеи. Я не хотел, честно. Потому что это как-то... совсем неправильно. Ведь если мы хотим исправить пакет, который уже установлен у нас в системе, значит кто-то (вероятно майнтейнер нашего дистрибутива) уже написал спек-файл, получил медаль за него, собрал пакет и положил его в репозиторий. Мы можем скачать из репозитория пакет src.rpm программы, которую хотим исправить, распаковать его и получить исходники программы и готовый спек. Мы распаковываем исходники программы, получаем каталог, например имя_проги-1.2.3, копируем его в имя_проги-1.2.3-orig, вносим нужные изменения, сохраняем, после чего командой

$ diff -urN имя_проги-1.2.3-orig имя_проги-1.2.3 > имя_проги-1.2.3_что_поменяли.patch

получаем патч для сборки. Кладём его рядом с архивом исходников, а в спек дописываем ровно две строчки: в шапку

Patch0:        имя_проги-1.2.3_что_поменяли.patch

и в секцию %prep

%patch0 -p1

После чего пересобираем. На выходе мы получаем готовый пакет для своей системы, собранный по всем правилам нашего дистрибутива, который ставится через пакетный менеджер со всеми сопутствующими этому плюшками (см. ниже). Его TopE может точно так же послать ingvaro и распить с ним пиво. Всё очень просто и лениво.
Что касается инсталлятора... идея конечно интересная, только кто будет отслеживать зависимости, например. Для rpm пакетов они прописываются в спеке при сборке, а при установке их отслеживает пакетный менеджер. Вам придётся паковать в свой архив все зависимости для своей программы или заставлять юзера самому их доустанавливать. Кроме того пакетный менеджер централизованно хранит в своей базе данные обо всех установленных пакетах с файлами и при удалении или обновлении пакета корректно обрабатывает все файлы. В общем я за rpmbuild и за пакетный менеджер. С ними сила!

Mageia 9b2
openSUSE 15.4

6 (2018-06-23 22:21:24 отредактировано alex_q_2000)

gaurii⇓ пишет:

Мне очень жаль, что мой пост каким-то образом послужил источником этой идеи. Я не хотел, честно.

Теперь уже ничего не поделаешь, gaurii. Хотел или не хотел - дело сделано, концы в воду т.с. )) Очень полезный материал изложили относительно патчей, спасибо. А я вот пришёл из гаража (палку там искал для вешалки) и... дай, думаю ещё чего-нибудь прикручу к креатору. Ну и, собственно, прикрутил волшебную кнопку RPM. Теперь можно по имени пакета сделать снапшот всех файлов, которые этот пакет содержит (rpm -ql pkg_name). Ведь нужно как-то развлекаться... big_smile

http://images.vfl.ru/ii/1529774790/fd7b354f/22223293_s.png  http://images.vfl.ru/ii/1529774791/f8467683/22223294_s.png

Если найдётся время, напишите пожалуйста ещё что-нибудь интересное про альтернативы rpmbuild. Например, вот была шумиха вокруг fpm на Хабре.
Здесь цитата из обсуждения:

Spoiler

bhavenger
19.12.14 в 12:04
Он простой, как три копейки. Например собрать собственный rpm-пакет из папки можно так(пример из оф. вики):
fpm -s dir -t rpm -n «slashbin» -v 1.0 /bin /sbin
Эта команда пакетирует все файлы из директорий /bin и /sbin в rpm-пакет slashbin версии 1.0.
В fpm нет огромных манов, это удобный инструмент от того, кто устал генерить валидные spec-файлы и всё, что там еще надо, для таких же уставших.
Если вы не мейнтейнер каких-то пакетов — то вся это возня вам практически наверняка не нужна.

Не приходилось ли Вам сталкиваться с этим "рукоделием"? )) Как и в случае с PatchCreator-ом, речь идёт о сборке пакетов с произвольным cодержимым. Заранее благодарен...

7

alex_q_2000, gaurii, спасибо за полезную информацию простыми и доходчивыми словами.
У меня к вам просьба, я пробовал собрать пакет по ману из нашей вики, но увы, кое-каких запчастей не хватило lol , в августе или сентябре иду в отпуск, создам тему  - Как собрать пакет.rpm - помогите освоить это волшебство, там требуются кое-какие нюансы, которые в инете искать придётся долго, например как знак "~" - тильда, когда был совсем чайником, то неделю искал что она значит, оказалось всего лишь файл/каталог в Домашнем хомяке /home/user_вася/Folder или ~/Folder big_smile

8 (2018-06-24 21:15:31 отредактировано alex_q_2000)

algri14⇓ пишет:

...в августе или сентябре иду в отпуск, создам тему  - Как собрать пакет.rpm - помогите освоить это волшебство, там требуются кое-какие нюансы, которые в инете искать придётся долго...

Такая тема обещает быть мега интересной. Однако, у меня в этом вопросе исключительно "шкурный" интерес, а gaurii является как раз ярким представителем канонических принципов сборки. Моё программерство в Lazarus обычно сводится к написанию различных гуёв+скриптов, либо интеграции второго в первое. Для работы программы в моём случае достаточно наличия GTK, а он есть у всех. Если нужен какой-то компонент (аля зависимость), например терминал для вывода результатов из консоли в человеческое окно, я разбираю нужный пакет (например sakura) на запчасти и запихиваю нужный кусок в программу, потом всё это добро сплющиваю rpmbuild-ом, если припрёт. Билл Гейтц именно так виндовс скомпилировал, кстати. )) В данном случае я пытаюсь сбить gaurii с понталыку и дать мне, бессовестному маргиналу, наводку на инструмент, который позволит сделать инсталлятор из произвольного содержимого без сишных приколов. Нужен выходной формат rpm, который менеджер пакетов не только скушает, но и не подавится. Предполагается, gaurii может меня послать, что в общем-то я то же учел, но попытка не пытка. big_smile Сишники за это и не любят всяких там паскалей - мы нарушаем их идиллию: приходим, начинаем рыть ямы на их вотчине нестандартными палками, воруем урожай плодово-ягодных культур, вскормленных исключительно правильными удобрениями. ))) Искренне надеюсь, что gaurii не расист. ))

К обсуждению канонических и "не очень" подходов нужно бы ещё народ подключить. Прошёл слух, что Zomby с отпуска вышел. XliN-а нужно отдельно как-то опять "отлавливать", он просто так не сдаётся. План прежний: берём продуктов на три дня, исследуем ареал обитания, дуем в манкИ, затем огораживаем территорию и выжидаем. Бубен с привлечением дождя беру на себя.

p.s.  Так, пора завязывать с демагогией, меня опять понесло. Но тема уж больно интересная... yikes

9 (2018-09-22 10:52:00 отредактировано alex_q_2000)

Использование FPM для создания пакетов в нескольких форматах

Вот, не выдержал. Немного поковырялся с fpm. Тот мужик с чужого форума был прав, - проще FPM не придумаешь. И чего я раньше его не юзал, прелесть какая. Здесь запишу, как пакет создавать, пока не забыл... big_smile

Установка fpm в Mageia:
-----------------------------------------------
urpmi --auto ruby-RubyGems ruby-devel libffi-devel rpm-build gcc make
gem install --no-ri --no-rdoc fpm

fpm --help  - вывести полный список ключей и др.

Делаем пакет из файла "/bin/mc" + каталога "/111" + с зависимостью от пакета "pkg-name" и версии 1.0:
-----------------------------------------------
fpm -s dir -t rpm -n "my-package-name" -v 1.0 /bin/mc /111 -d "pkg-name"
или с использованием списка файлов и папок
fpm -s dir -t rpm -n "my-package-name" -v 1.0 --inputs "файл со списком файлов и папок" -d "pkg-name"

Результат:
-----------------------------------------------
Получаем готовый пакет my-package-name-1.0-1.x86_64.rpm

Ставится/удаляется/подтягивает зависимости. Еслиб не тема - не в жизнь бы не полез в эту страсть, так и парился бы с rpmbuild и спЕками. Однако, есть желание получить больше информации насчёт "подводных камней" от спецов. Пойду порадую AVOTIŅI. Он там какой-то "лазерный квазинтатор" то же хотел собрать в rpm. ))

10 (2018-06-25 09:21:54 отредактировано gaurii)

algri14 пишет:

У меня к вам просьба, я пробовал собрать пакет по ману из нашей вики, но увы, кое-каких запчастей не хватило lol , в августе или сентябре иду в отпуск, создам тему  - Как собрать пакет.rpm - помогите освоить это волшебство

Статья в вики хорошая, очень хорошо азы расписаны, я сам по ней собирать учился. Пользуясь случаем, хочу поблагодарить написавшего её автора. Единственая деталь, непонятно, зачем предлагается собирать пакеты из-под рута. Я всегда собираю из-под своего пользователя и всегда всё выходит прекрасно. Я тоже в отпуск иду в августе, поможем. Ещё зови XliN-а и Zomby. Они сборщики опытные, уверен - порасскажут всякого.

alex_q_2000 пишет:

Вот, не выдержал. Немного поковырялся с fpm. Тот мужик с чужого форума был прав, - проще FPM не придумаешь. И чего я раньше его не юзал, прелесть какая

Я с этой штукой раньше дела не имел, глянул описание... Ну ладно, упаковать готовые файлы-каталоги она в пакет может и даже может зависимости прописать, а конпелять кто будет?!! Суть-то рпмбилдерства в том чтобы взять архив исходников, к нему спек, патчи, что там ещё есть, запустить rpmbuild и получить на выходе готовый к употреблению пакет с откомпилированными бинарями, либами, десктоп-файлами и прочим. Я вот, во времена свооей линуксовой юности устанавливал программы, которых не было в репозитории, из исходников, как тогда учили с помощю трёх волшебных команд configure && make && make install. И постоянно была головная боль с тем, что что-то не компилится, после установки это всё ставится неизвестно куда, приходится сохранять каталог сборки, чтобы можно было сделать make uninstall... Какова была моя радость, когда мне показали, что это можно делать лёгким движением руки. Ну, при наличии спека. А если из спека убрать всё, что относится к сборке из исходников и оставить только раскладку файлов по каталогам, то он будет не сильно сложнее портянки командной строки fpm для создания rpm.

Конечно, разработчику ПО писать спек с нуля для своей программы - то ещё развлечение, так они обычно этого и не делают. Опакечивать сырцы задача майнтейнеров дистрибутивов. Можно и вообще не опакечивать, а распространять в архиве, как firefox, например. Скачал архив, распаковал, запустил бинарь и вперёд. Живёт в своём каталоге и в систему не лезет. Сейчас, говорят, ещё в моде всякие Appimage и Flatpak`и. Короче говоря, способы превратить линукс в винду - есть smile
ps А за шпаргалку по CMake - спасибо.

Mageia 9b2
openSUSE 15.4

11

algri14 пишет:

файл/каталог в Домашнем хомяке /home/user_вася/Folder или ~/Folder big_smile

Это справедливо если только вы не под root. tongue Иначе ~/Folder это /root/Folder wink

Mageia6, KDE, LXQt, x86_64.
Человек человеку - волк, а зомби зомби - зомби!

12

alex_q_2000,  Видел, что в https://github.com/google/spatial-media … master.zip
есть файл. *.spec Что с ним делать?

Mageia 9 KDE

13

gaurii пишет:

Конечно, разработчику ПО писать спек с нуля для своей программы - то ещё развлечение, так они обычно этого и не делают. Опакечивать сырцы задача майнтейнеров дистрибутивов.

Именно так, программисту главное создать программу, а будет ли rpm-пакет этой программы для конкретного дистрибутива - вопрос к майнтейнеру.

Mageia6, KDE, LXQt, x86_64.
Человек человеку - волк, а зомби зомби - зомби!

14 (2018-06-25 13:45:36 отредактировано alex_q_2000)

gaurii⇓ пишет:

Сейчас, говорят, ещё в моде всякие Appimage и Flatpak`и. Короче говоря, способы превратить линукс в винду - есть

Обзор Appimage и Flatpak

gaurii⇓ пишет:

А если из спека убрать всё, что относится к сборке из исходников и оставить только раскладку файлов по каталогам, то он будет не сильно сложнее портянки командной строки fpm для создания rpm.

"Портянка.spec" lol А как ещё собирать из готового, если всё уже скомпилено до нас? Нет, нет, даже не отрицайте, fpm - вещь в хозяйстве нужная. Согласен, виндой конечно немного попахивает. Но удобно же. big_smile

Zomby⇓ пишет:

Именно так, программисту главное создать программу, а будет ли rpm-пакет этой программы для конкретного дистрибутива - вопрос к майнтейнеру.

Привет, Zomby. Эвон как. А я думал, что всё один чел делает. Т.е. программа может быть отписана на любом языке, а её сборкой в пакет будет уже другой чел заниматься? А как же они увязывают действия друг-друга в этом случае?

15

alex_q_2000 пишет:

А я думал, что всё один чел делает. Т.е. программа может быть отписана на любом языке, а её сборкой в пакет будет уже другой чел заниматься? А как же они увязывают действия друг-друга в этом случае?

Приве-привет! Ну, может и один конечно. Тоесть, программист может выступить в роли майнтейнера своей программы и собрать пакет с этой прогой (если захочет).
Это как в анекдоте про 2 стакана на прикроватной тумбочке, один с водой, а другой пустой (могу захотеть пить, могу не захотеть smile ).

А майнтейнер собирает программу в пакет. Вопросы к программисту, если таковые возникнут в процессе сборки, обычно можно задать программисту по e-mail. Программы для опакечивания
ведь майнтейнер не из воздуха берёт.

Mageia6, KDE, LXQt, x86_64.
Человек человеку - волк, а зомби зомби - зомби!

16

Zomby⇓ пишет:

Программы для опакечивания ведь майнтейнер не из воздуха берёт.

Понятно. Назовут же - "майнтейнер". Вот так скажут где-нибудь и сиди репу чеши, обозвали тебя или нет. Понятнее было бы "Собиральщик пакетов". Хотя, то же нет; могут подумать, что бомж какой. Ладно, пусть будет майнтейнер. Значит так... Пойду я девелОпить и майнтЕйнить гуй для fpm... (Госспади, чуть язык не сломал) good

17

alex_q_2000⇓ пишет:

Архив bbcolor-1.tar.gz с нужными файлами (бинарник, иконка, ярлык и др)

Если начать с этого места, квест получится не полным. А если начать с

"]Архив bbcolor-1.tar.gz с нужными файлами (исходники)", то создание RPM  становится уже гораздо интереснее и на  FPM смотришь  по другому.

18

Народ! На форуме нет модераторов, но что мешает нам самим придерживаться правила писать в теме только по теме ( извините за тавтологию).  Тема то про "Dolphin в Магее 6", а здесь уже обсуждают сборку,  майнтейнеров и bbcolor.

19

Сообщения перенёс, поставил после Сообщения №3 благо что автор уже сам создал тему good

alex_q_2000⇓ пишет:

пока нас тут не разогнали... big_smile

Разгонять никто не собирается, но замечание kvv-vp правильное сделал:

Темы я пытаюсь модерировать, но иногда разговор так переплетается, что и не знаешь с какого места разделять сообщения.
Поэтому давайте на самоконтроле - создавайте отдельные темы, чтобы не засорять основную и не делать из одной "сиамского близнеца" big_smile

Спасибо сказали: alex_q_20001

20 (2018-06-29 14:24:49 отредактировано alex_q_2000)

AVOTIŅI⇓ пишет:

alex_q_2000,  Видел, что в https://github.com/google/spatial-media … master.zip
есть файл. *.spec Что с ним делать?

...из README
## Building standalone GUI application
Install [PyInstaller](http://pythonhosted.org/PyInstaller/), then run the
following: pyinstaller spatial_media_metadata_injector.spec

Пишут, как я понимаю, что для создания приложения с графическим интерфейсом (может бинарь?) следует использовать некий PyInstaller. Речи про RPM и rpmbuild тут не идёт, если Вы об этом. Ссылка на описание PyInstaller... Надо искать спеца по питону и начать надо с BoDun-а. Не буквально, конечно, три дня там не просыхать и т.п. (шучу), а с нашего BoDun. Он единственный проявил живой интерес к питоновской проге. Подозреваю, что он в курсе питоновских заморочек и имеет опыт работы с этим "зверьком". Так что с удовольствием передаю ему эстафету. Человек по-всему толковый, может подскажет подробнее. А я в питоне нивзубногой, коллега. wink

21 (2018-09-29 16:13:00 отредактировано alex_q_2000)

Для удобства оба проекта были опакечены и ставятся в "Системные". Протестированы на VM MgaRemix-6. RPM-ы лежат здесь...

Спасибо сказали: algri14, AVOTIŅI2

22 (2018-09-17 11:54:56 отредактировано alex_q_2000)

Браузер Pale Moon для Mageia

В соответствии с инструкцией по ручной установке из тарбола, с помощью RPMCreator были собраны пакеты RPM.

После установки запустите браузер и установите переключатель языков. Установите русский язык и переключите. Здесь кучка расширений, а здесь кучка тем для браузера Pale Moon.

Идея опакетить добро для Магии - мера вынужденная, поскольку с переходом на новый движок, разработчики Moonchild Productions не сделали их традиционный инсталлятор. Старую версию Pale Moon, если она была установлена ранее, можно удалить с помощью pminstaller (находится в папке SRC).

p.s. Себе поставил на флешку Mageia3-Win10. Полёт нормальный. yikes

Спасибо сказали: algri141

23 (2018-09-20 20:37:25 отредактировано alex_q_2000)

Zomby⇓ пишет:

Тоесть, программист может выступить в роли майнтейнера своей программы и собрать пакет с этой прогой (если захочет).

Здравcтвуйте, Zomby

У меня вопрос относительно сборки rpm...

%pre - этот сценарий выполняется перед установкой пакета в систему
%post - этот сценарий выполняется после установки пакета в систему
%preun - этот сценарий выполняется перед удалением пакета из системы
%postun - этот сценарий выполняется после удаления пакета из системы

Напомню, что я иду нетрадиционным путём создания пакетов, т.е. через RPMCreator -> FPM (см. скриншот в начале темы). Основная задача у меня насобирать в пакет уже готовое, лежащее в нужных местах добро и заплющить в тру-rpm. До сих пор как-то обходился сценариями %post и %postun, в основном для создания ссылок и чистой деинсталляции пакета. Однако у FPM есть и %pre %preun (там они иначе называются). Вот думаю, пригодится ли, если в моём RPMCreator-e предусмотреть и сценарии %pre %preun...

Вопрос в следующем: нельзя ли привести пример (или объяснить на пальцах), для чего именно можно использовать %pre %preun, чтобы мне оценить их нужность? Или %post и %postun достаточно, если добро я не компилирую, а только в кучу собираю?

Заранее благодарен... drinks

p.s. Есть у rpm ещё мега-хитрый параметр --epoch, но как пишут, с ним лучше не связываться. big_smile

24

alex_q_2000, что-то народ совсем затих, попробуй спросить на https://unixforum.org/index.php

25

для чего именно можно использовать %pre %preun, чтобы мне оценить их нужность? Или %post и %postun достаточно, если добро я не компилирую, а только в кучу собираю?

Это зависит от того, что должно меняться в системе до появления/удаления файлов пакета.

Mageia 8 x86_64 / FVWM