Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
На этот форум и wiki ведут ссылки с официальных сайтов Mageia.
У форума нет нигде и никаких чатов, wiki пока не работает (в процессе подключения), идёт небольшая реорганизация.Форум закрывается, подробности в теме «Реорганизация форума».
Mageia Russian Community Forum → Программирование → PatchCreator и RPMCreator
Это зависит от того, что должно меняться в системе до появления/удаления файлов пакета.
Просто подумал, что после установки всегда можно сделать то, что перед ней. К тому же увязывать с обновлением как-то логичнее. Ок, тогда ещё одну вкладку прилеплю, отдельно с этими скриптами. Для полноты картины т.с. 
Просто подумал, что после установки всегда можно сделать то, что перед ней
не всегда. Иногда надо сделать бэкап конфига, к примеру, перед установкой новой версии с новым конфигом, но с тем же именем. Это самый очевидный пример.
Иногда надо сделать бэкап конфига, к примеру, перед установкой новой версии с новым конфигом, но с тем же именем.
И то правда. Заодно проверил, как работают скрипты "Перед установкой".
RPMCreator v0.9-6 [upd: 22.09.2018]
Пакеты ruby-RubyGems ruby-devel libffi-devel rpm-build gcc make - теперь зависимости самого пакета RPMCreator.
Команда установки FPM (которая gem install --no-ri --no-rdoc fpm) теперь прописана в сам пакет (%post).
Теперь RPMCreator сам подтягивает/обновляет/устанавливает все наисвежайшие зависимости для себя, любимого. Пользователю больше не нужно вводить пароль для инсталляции FPM и других ruby-зависимостей. Он сразу переходит к сборке своего пакета. Правда, пришлось пожертвовать наглядностью в угоду автоматизации, а мне нравилось вводить пароль и наблюдать, как ставится gem.
Тестирование приветствуется. 
p.s. Самое прикольное во всём этом, что RPMCreator в процессе сборки собственного пакета как бы делает сам себя. 
Ссылка на RPM-ы и проекты RPMCreator/PatchCreator для наглядности...
Концепция изменилась. Теперь RPMCreator работает напрямую с rpmbuild. Проект на базе FPM временно заморожен.
Дополнительные бонусы: создаются spec и src.rpm
Рабочий каталог: ~/rpmbuild
Это зависит от того, что должно меняться в системе до появления/удаления файлов пакета.
Вопрос также адресован всем, кто занимается сборкой RPM...
В процессе "сборки" пакета из файлов и папок непосредственно через rpmbuild, столкнулся с массой ненужных проверок - неиспользуемых библиотек, синтаксиса исходников (на питоне, в частности), перловые проги ещё не собирал и др. Для интереса проверял работу RPMCreator и в Росе, а там RPM5 (и другой список групп, кстати. В Магии группы от Федоры). Так вот, в Росе он пакеты собирает, но жутко мешается какой-то rpmlint. Весь экран захламляет матерной писаниной, относящейся к компиляции, которой у меня нет + тратит на это время. В Магии (RPM4) пакет создаётся гораздо "чище".
На данный момент пытаюсь унять rpmbuild в spec-е:
#Allow building noarch packages that contain binaries
%define _binaries_in_noarch_packages_terminate_build 0
#Disable RPM-s automatic dependency
AutoReq: no
AutoProv: no
AutoReqProv: no
#Disable Python dependency
AutoReqProv: nopython
%define __python %nil
#Other disable
%global debug_package %{nil}Очень хочется убрать весь ненужный мусор, относящийся к компиляции и другие "придирки" rpmbuild + сделать процесс сборки быстрее. Например, rpmlint пишет Warning в случае, если Summary и %description имеют одинаковую первую строку. )) Идиотизм...
Здесь пример рабочего спека для RPMCreator, сделанный им же:
Вопрос: как можно НАГЛУХО отключить все ненужные проверки rpmbuild и rpmlint, которые относятся к компиляции/синтаксису, лИбам и прочей лабуде?
Ужас, дикий ужас.
Ужас, дикий ужас.
)) Ладно возмущаться-то. Я понимаю, что по сану положено. Но сами же прошлый раз "спек да спек". Ведь предлагал без этой требухи через fpm, так ведь нет, по правилам надо, едрён батон. По делу лучше что-нибудь скажите.
alex_q_2000, всё не так абсолютно, лучше вообще не делать, а заняться чем-то другим, например, доработать Pascal стек в Mageia, ибо знания есть, но не в то русло.
alex_q_2000, всё не так абсолютно, лучше вообще не делать
https://www.youtube.com/watch?v=p5ga9SlKLrk Что не так?
По делу лучше что-нибудь скажите.
AlexL обычно не удосуживает себя разъяснениями если у него нет заинтересованности..
Хотя alex_q_2000 задал конкретный вопрос и требуется конкретный ответ а не рассуждения на заданную тему.
Так вот, в Росе он пакеты собирает, но жутко мешается какой-то rpmlint. Весь экран захламляет матерной писаниной, относящейся к компиляции, которой у меня нет + тратит на это время
Пробовал я сделать пакетную сборку Росы, но ничего не получилось.
Какие то конфликты между пакетами, что то не загружается и в итоге сборка не запускается.
Хватало и " матерной писанины". Но я работал на urpmi и RPM5 отличается от RPM4
Почитал и применил уже другие опции работы для RPM5 и хотя " матерной писанины" уменьшилось, но все равно сборка не получилась.
В Магее же как не собирай все запускается и работает.
Пришел к выводу, что в Росе ситуация как в Магее годом ранее.
KDE уже устарел, а Plasma до конца не отработана.
так ведь нет, по правилам надо, едрён батон.
Я так понял, что Вы не всё знаете, но я по доброму завидую даже этому. Так как я совсем ничего не понимаю в сборке пакетов, то вроде бы не корректно моё суждение, но попробую.
Есть на данный момент установленные правила сборки пакета и их надо придерживаться, такие пакеты кладутся в репо без претензий(без разницы - оффицальный репо или неофф). А вот неправильно собранные пакеты в репо ложить нельзя, НО пользоваться можно, при этом давая ссылку на скачивание надо давать комментарии по поводу сборки (что в общем то Вы делали, но надо всё таки более конкретно).
Не совсем, но всё таки приемлемо иметь хотя бы такой пакет, чем иметь "правильно" собранный, но неработающий
О правильной сборке RPM-пакетов
Что делает сборщик пакетов:
● Определяет требования для установки ПО
● Составляет описание программы
● Ведет журнал изменений
● Предварительно компилирует ПО
● Определяет адреса установочных директорий и способ установки ПО
● Добавляет вспомогательные скрипты, чтобы обеспечить успешную установку
● Добавляет скрипты Glue для апгрейда/даунгрейда
Система для сборки пакетов
● Минимальный набор пакетов
● Система должна быть чистой
● Должна быть частью более крупной автоматизированной системы
Чего следует избегать при сборке:
● Доступа к сетям
● Доступа к внешним кодам
● Влияния на другие пакеты и их файлы
● Чрезмерной зависимости от системных сервисов
● Предварительно скомпилированного ПО
Вывод: сборщик пакетов должен предварительно компилировать ПО, чтобы его избегать. Другими словами, все обязаны компилировать и проверять своё ПО ещё раз в процессе сборки пакета. Видимо об этом речь.
А если из спека убрать всё, что относится к сборке из исходников и оставить только раскладку файлов по каталогам, то он будет не сильно сложнее портянки командной строки fpm для создания rpm.
Здравствуйте, gaurii
Разбирая на запчасти пакет yandex-disk-indicator-1.10.6-1.src.rpm (ROSA 2016.1), спек которого очень напоминает те, что создаёт RPMCreator (спек-портянка), наткнулся на такую запись зависимостей:
Requires: typelib(AppIndicator3)Т.е. имена нужных пакетов указываются не прямо, а через вот эту typelib(бла-бла). В итоге готовый пакет автоматически требовал к установке нужный lib64appindicator3-gir0.1-12.10.0-19.mga6.x86_64.rpm или libappindicator3-gir0.1-12.10.0-19.mga6.i586.rpm, в зависимости от разрядности системы. Эта инструкция позволяла запилить пакет noarch, что очень удобно.
В других спеках я видел нечто аналогичное:
Requires: devel(libcinnamon-desktop)
Requires: pkgconfig(cinnamon-desktop)Что означает такая форма записи при определении зависимостей в спеке и где об этом можно почитать?
Заранее благодарен...
Requires: typelib(AppIndicator3)Т.е. имена нужных пакетов указываются не прямо, а через вот эту typelib(бла-бла). В итоге готовый пакет автоматически требовал к установке нужный lib64appindicator3-gir0.1-12.10.0-19.mga6.x86_64.rpm или libappindicator3-gir0.1-12.10.0-19.mga6.i586.rpm, в зависимости от разрядности системы. Эта инструкция позволяла запилить пакет noarch, что очень удобно.
Интересно, надо будет при очередном обновлении своей сборки megasync попробовать.
Я только писал:
Requires: pkgconfig(cinnamon-desktop)
Как писал когда-то один умный человек на этом форуме:
НЕ-Е-Е-Т!!! Не надо писать в спеках %{_lib}qtwebkit2.2-devel !!!! В спеках надо писать 'pkgconfig(QtWebKit)'! Господа, неужели это так сложно - сделать 'urpmq --provides devel-пакет' и выбрать из списка правильную строку, которая не будет зависеть от архитектуры? Например QtWebKit предлагает два таких варианта: qtwebkit-devel и pkgconfig(QtWebKit). Предпочтение следует отдавать варианту с pkgconfig (если он есть).
Опять же https://fedoraproject.org/wiki/Packagin … ldRequires
В спеках надо писать 'pkgconfig(QtWebKit)'! Господа, неужели это так сложно - сделать 'urpmq --provides devel-пакет' и выбрать из списка правильную строку, которая не будет зависеть от архитектуры? Например QtWebKit предлагает два таких варианта: qtwebkit-devel и pkgconfig(QtWebKit). Предпочтение следует отдавать варианту с pkgconfig (если он есть).
Огроменное спасибо, gaurii! И olelukoie...
Провел эксперимент на "зондирование" этих "обтекаемых" описаний зависимостей devel-пакетов:
urpmq --provides lib64mpv-devel
Увидел, что автоматическую установку lib64mpv-devel или libmpv-devel без указания архитектуры можно "описать" несколькими способами:
mpv-devel
pkgconfig(mpv)Предпочтительный способ:
Requires: pkgconfig(mpv)И проверил в реале:
urpmi mpv-devel
или
urpmi "pkgconfig(mpv)"Здесь копия из wiki по Fedora, чтобы не спёрли:
Вывод: Это мега-очешуенно, gaurii!!! Теперь ZVVOnlineTV можно сделать "бесполым" (noarch).
UPD: Дополнительно, Provides описаны для каждого пакета на pkgs.org.
Опять же...
Здравствуйте, gaurii.
Если у Вас есть время, подскажите пожалуйста по этим вопросам...
1. Когда я собираю lib-пакет из библиотек *.so, rpmbuild сам создаёт симлинки, которые так же приходится добавлять в rpm. Это нормально?
2. В Винде dll можно закинуть прямо в папку с программой и распространять. А в Linux можно *.so запихивать прямо в пакет с программой, что бы их по системе "не размазывать"? Или так нельзя?
Заранее благодарен...
Симлинки создаются потому, что программы требуют библиотеку определённой мажорной версии. А минорная версия может быть в разных дистрибутивах разная, может поменяться после обновления и т.п. Поэтому создаётся симлинк с номером мажорной версии, который указывает на собственно библиотеку. Если взять для примера нашу libmpv1, то в пакете версии 0.25 симлинк libmpv.so.1 указывает на libmpv.so.1.24.0 , а в версии 0.27 на libmpv.so.1.25.0. Если нашей проге нужна библиотека libmpv1, она её найдёт по ссылке, независимо от номера минорной версии. Это нормально и правильно.
Видимо, есть гайдлайны для разработчиков дистрибутивов, которые предписывают паковать библиотеки в отдельные пакеты. Это лучше у Алекса спросить, можно или нельзя паковать вместе.
Можно, но виндовый способ не приветствуется.
Лучше чтобы каждая отдельная единица была в своём пакете. Т.е. если библиотека просто библиотека, то чтобы она была в своём отдельном пакете. Тогда будет проще обновлять систему.
Другой вопрос, что в наиболее популярных дистрибутивах даже одну отдельную единицу могут покрошить на множество мелких пакетиков. В т.ч. пакет библиотеки разобрать как минимум на два пакета: первый с бинарником библиотеки, а второй - -dev или -devel - с заголовочными файлами и прочими файлами для разработки на основе этой библиотеки. К такому тоже можно относиться по-разному, и, например, в тех же дистрибутивах Slackware и Arch/Manjaro так не принято. Там любят крупные пакеты. В т.ч. если библиотека не сама по себе, а идёт в составе какой-либо программы, то она вполне может оказаться целиком и полностью в пакете с этой программой.
Можно, но виндовый способ не приветствуется.
Здравствуйте, AlexL. К gaurii я уже приставал. Теперь - вот, сами понимаете...
У меня, как всегда назрели вопросы, поражающие своей глубиной и потаённым смыслом. Если найдётся время, объясните пожалуйста эти моменты.
В моём мега-крутом RPMCreator-е при создании пакета в секциях %post и %postun (обновление), предусмотрены некоторые полезные "шаблоны" для всяких апдейтов, вроде этих:
---
#ldconfig - обновление кеша динамических либ
#update-desktop-database -q /usr/share/applications - обновление базы приложений (ярлыков, видимо)
#update-mime-database /usr/share/mime - обновление ассоциаций: тип файла/иконка
#gtk-update-icon-cache -q -f /usr/share/icons/hicolor - обновление иконок
Вопросы:
---
1. Какие ещё апдейты выполняются/требуются/не требуются после установки пакета?
2. Какова необходимость этих апдейтов, нужны ли они, или "по-ситуации"?
3. Если программа ставит библиотеки и кладёт их в каталог, отличный от /usr/lib /usr/lib64, требуется ли предусматривать какой-нибудь ldconfig /папка/с/либами?
Спасибо.
Ничего не нужно. Вообще.
Лучше чтобы каждая отдельная единица была в своём пакете.
Здравствуйте, saahriktu.
Пока gaurii и AlexL от меня отдыхают, решил вопрос задать Вам, на примере т.с.
Вот, на гит-хабе имеется программа qjournalctl:
master-версия с исправлениями месячной давности: https://github.com/pentix/qjournalctl
И release v0.5.1, датированная февралём этого года: https://github.com/pentix/qjournalctl/releases
Вопрос: Если я надумал всё это (или другое) добро скомпилить/опакетить, следует отдать предпочтение master-у или release?
Заранее благодарен...
alex_q_2000, Мартин, автор mseide, msegui, mselang выпустил релиз, после этого внёс исправления в master и умер. На чём основывать сборку пакета? Конечно, на master. То есть на исправленной версии. Но Мартин был бриллиантом, у него любой срез стабилен, ничего не ломал при фиксах. А у других master может быть хуже релиза.
Mageia Russian Community Forum → Программирование → PatchCreator и RPMCreator
Работает на PunBB, при поддержке Informer Technologies, Inc, при поддержке sevo44.ru