26 (2018-09-21 20:22:32 отредактировано alex_q_2000)

saahriktu⇓ пишет:

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

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

27

alex_q_2000⇓ пишет:

Просто подумал, что после установки всегда можно сделать то, что перед ней

не всегда. Иногда надо сделать бэкап конфига, к примеру, перед установкой новой версии с новым конфигом, но с тем же именем. Это самый очевидный пример.

ROSA Desktop Fresh R11.1 EE 2016.1 Desktop 64-бит
Спасибо сказали: alex_q_20001

28

TopE⇓ пишет:

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

И то правда. Заодно проверил, как работают скрипты "Перед установкой". smile

29 (2018-09-27 20:06:51 отредактировано alex_q_2000)

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.

Тестирование приветствуется. yikes

p.s. Самое прикольное во всём этом, что RPMCreator в процессе сборки собственного пакета как бы делает сам себя. big_smile

Ссылка на RPM-ы и проекты RPMCreator/PatchCreator для наглядности...

30 (2018-09-29 16:08:08 отредактировано alex_q_2000)

Концепция изменилась. Теперь RPMCreator работает напрямую с rpmbuild. Проект на базе FPM временно заморожен. yikes

Дополнительные бонусы: создаются spec и src.rpm
Рабочий каталог: ~/rpmbuild

Ссылка на RPMCreator...

31

saahriktu⇓ пишет:

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

Вопрос также адресован всем, кто занимается сборкой RPM... yikes

В процессе "сборки" пакета из файлов и папок непосредственно через 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 имеют одинаковую первую строку. )) Идиотизм... big_smile

Здесь пример рабочего спека для RPMCreator, сделанный им же:

Spoiler
#Created automatically by RPMCreator v1.0-3

#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}

Name: rpmcreator
Version: 1.0
Release: 3.mga6
Group: Applications/System
Packager: aLEX_gRANT (Mageia Russian Community)
Vendor: MRC
License: GPLv3+
URL: [url]https://forum.mageia.org.ru/viewtopic.php?id=1915[/url]

Source: %{name}-%{version}.tar.gz

Requires: sakura rpm-build gcc make
BuildRequires: sakura rpm-build gcc make

Summary: RPMCreator - GUI for rpmbuild

%description
RPMCreator - GUI for rpmbuild
Program to create RPM packages from arbitrary files and folders

%prep
%setup -c PACKAGE -n PACKAGE

%install
cp -rf * %{buildroot}

%clean
rm -rf * %{buildroot}

%pre

%post

%preun

%postun
if [ $1 -eq 0 ]; then rm -rf /usr/share/RPMCreator+GUI; fi

%files
%defattr(0755, root, root)

/usr/bin/rpmcreator
%dir /usr/share/RPMCreator+GUI/
/usr/share/RPMCreator+GUI/unit1.lfm
/usr/share/RPMCreator+GUI/RPMCreator.lps
/usr/share/RPMCreator+GUI/RPMCreator.ico
/usr/share/RPMCreator+GUI/unit2.lfm
%dir /usr/share/RPMCreator+GUI/ico/
/usr/share/RPMCreator+GUI/ico/load.png
/usr/share/RPMCreator+GUI/ico/folder+.png
/usr/share/RPMCreator+GUI/ico/file+.png
/usr/share/RPMCreator+GUI/ico/RPMCreator.ico
/usr/share/RPMCreator+GUI/ico/PatchCreator.ico
/usr/share/RPMCreator+GUI/ico/select-all.png
/usr/share/RPMCreator+GUI/ico/save.png
/usr/share/RPMCreator+GUI/ico/patch.png
/usr/share/RPMCreator+GUI/ico/rpm.png
/usr/share/RPMCreator+GUI/ico/delete.png
/usr/share/RPMCreator+GUI/RPMCreator.lpi
/usr/share/RPMCreator+GUI/unit2.pas
/usr/share/RPMCreator+GUI/RPMCreator
/usr/share/RPMCreator+GUI/RPMCreator.res
/usr/share/RPMCreator+GUI/unit1.pas
/usr/share/RPMCreator+GUI/settings.xml
/usr/share/RPMCreator+GUI/RPMCreator.pas
%dir /usr/share/RPMCreator+GUI/backup/
/usr/share/RPMCreator+GUI/backup/unit1.lfm
/usr/share/RPMCreator+GUI/backup/RPMCreator.lps
/usr/share/RPMCreator+GUI/backup/unit2.lfm
/usr/share/RPMCreator+GUI/backup/RPMCreator.lpi
/usr/share/RPMCreator+GUI/backup/unit2.pas
/usr/share/RPMCreator+GUI/backup/unit1.pas
/usr/share/RPMCreator+GUI/backup/PatchCreator.lpr
/usr/share/RPMCreator+GUI/backup/PatchCreator.lps
/usr/share/RPMCreator+GUI/backup/PatchCreator.lpi
/usr/share/RPMCreator+GUI/unique_utils.pas
/usr/share/RPMCreator+GUI/lclstrconsts.po
%dir /usr/share/RPMCreator+GUI/lib/
%dir /usr/share/RPMCreator+GUI/lib/i386-linux/
/usr/share/RPMCreator+GUI/lib/i386-linux/unit1.lfm
/usr/share/RPMCreator+GUI/lib/i386-linux/unit1.ppu
/usr/share/RPMCreator+GUI/lib/i386-linux/unit2.lfm
/usr/share/RPMCreator+GUI/lib/i386-linux/unique_utils.ppu
/usr/share/RPMCreator+GUI/lib/i386-linux/PatchCreator.res
/usr/share/RPMCreator+GUI/lib/i386-linux/PatchCreator.or
/usr/share/RPMCreator+GUI/lib/i386-linux/RPMCreator.res
/usr/share/RPMCreator+GUI/lib/i386-linux/unit1.o
/usr/share/RPMCreator+GUI/lib/i386-linux/unique_utils.o
/usr/share/RPMCreator+GUI/lib/i386-linux/PatchCreator.o
/usr/share/RPMCreator+GUI/lib/i386-linux/unit2.o
/usr/share/RPMCreator+GUI/lib/i386-linux/PatchCreator.compiled
/usr/share/RPMCreator+GUI/lib/i386-linux/RPMCreator.compiled
/usr/share/RPMCreator+GUI/lib/i386-linux/RPMCreator.o
/usr/share/RPMCreator+GUI/lib/i386-linux/RPMCreator.or
/usr/share/RPMCreator+GUI/lib/i386-linux/unit2.ppu
%dir /usr/share/RPMCreator+GUI/lib/i386-win32/
/usr/share/RPMCreator+GUI/lib/i386-win32/unit1.lfm
/usr/share/RPMCreator+GUI/lib/i386-win32/unit1.ppu
/usr/share/RPMCreator+GUI/lib/i386-win32/PatchCreator.res
/usr/share/RPMCreator+GUI/lib/i386-win32/PatchCreator.or
/usr/share/RPMCreator+GUI/lib/i386-win32/unit1.o
/usr/share/RPMCreator+GUI/lib/i386-win32/PatchCreator.o
/usr/share/RPMCreator+GUI/lib/i386-win32/PatchCreator.compiled
/usr/share/RPMCreator+GUI/lclstrconsts.ru.po
/usr/share/icons/rpmcreator.png
/usr/share/applications/rpmcreator.desktop

Вопрос: как можно НАГЛУХО отключить все ненужные проверки rpmbuild и rpmlint, которые относятся к компиляции/синтаксису, лИбам и прочей лабуде?

32

Ужас, дикий ужас.

Разработчик, мейнтейнер, переводчик, по всем вопросам.

33 (2018-09-30 13:33:33 отредактировано alex_q_2000)

AlexL⇓ пишет:

Ужас, дикий ужас.

)) Ладно возмущаться-то. Я понимаю, что по сану положено. Но сами же прошлый раз "спек да спек". Ведь предлагал без этой требухи через fpm, так ведь нет, по правилам надо, едрён батон. По делу лучше что-нибудь скажите. yikes

34

alex_q_2000, всё не так абсолютно, лучше вообще не делать, а заняться чем-то другим, например, доработать Pascal стек в Mageia, ибо знания есть, но не в то русло.

Разработчик, мейнтейнер, переводчик, по всем вопросам.

35

AlexL⇓ пишет:

alex_q_2000, всё не так абсолютно, лучше вообще не делать

https://www.youtube.com/watch?v=p5ga9SlKLrk Что не так? smile

36 (2018-09-30 20:48:42 отредактировано ingvaro)

alex_q_2000⇓ пишет:

По делу лучше что-нибудь скажите.


AlexL обычно не удосуживает себя разъяснениями если у него нет заинтересованности..
Хотя alex_q_2000 задал конкретный вопрос и требуется конкретный ответ а не рассуждения на заданную тему.

37 (2018-09-30 22:41:35 отредактировано ingvaro)

alex_q_2000⇓ пишет:

Так вот, в Росе он пакеты собирает, но жутко мешается какой-то rpmlint. Весь экран захламляет матерной писаниной, относящейся к компиляции, которой у меня нет + тратит на это время

Пробовал я сделать пакетную сборку Росы, но ничего не получилось.
Какие то конфликты между пакетами, что то не загружается и в итоге сборка  не запускается.
Хватало и " матерной писанины". Но я работал на urpmi и RPM5 отличается от RPM4
Почитал и применил уже другие опции работы для RPM5 и хотя " матерной писанины" уменьшилось, но все равно  сборка не получилась.
В Магее же как не собирай все запускается и работает.
Пришел к выводу, что в Росе ситуация как в Магее годом ранее.
KDE уже устарел, а Plasma до конца не отработана.

38

alex_q_2000⇓ пишет:

так ведь нет, по правилам надо, едрён батон.

Я так понял, что Вы не всё знаете, но я по доброму завидую даже этому. Так как я совсем ничего не понимаю в сборке пакетов, то вроде бы не корректно моё суждение, но попробую.
Есть на данный момент установленные правила сборки пакета и их надо придерживаться, такие пакеты кладутся в репо без претензий(без разницы - оффицальный репо или неофф). А вот неправильно собранные пакеты в репо ложить нельзя, НО пользоваться можно, при этом давая ссылку на скачивание надо давать комментарии по поводу сборки (что в общем то Вы делали, но надо всё таки более конкретно).
Не совсем, но всё таки приемлемо иметь хотя бы такой пакет, чем иметь "правильно" собранный, но неработающий

39

О правильной сборке RPM-пакетов

Что делает сборщик пакетов:
● Определяет требования для установки ПО
● Составляет описание программы
● Ведет журнал изменений
Предварительно компилирует ПО
● Определяет адреса установочных директорий и способ установки ПО
● Добавляет вспомогательные скрипты, чтобы обеспечить успешную установку
● Добавляет скрипты Glue для апгрейда/даунгрейда

Система для сборки пакетов
● Минимальный набор пакетов
● Система должна быть чистой
● Должна быть частью более крупной автоматизированной системы

Чего следует избегать при сборке:
● Доступа к сетям
● Доступа к внешним кодам
● Влияния на другие пакеты и их файлы
● Чрезмерной зависимости от системных сервисов
Предварительно скомпилированного ПО

Вывод: сборщик пакетов должен предварительно компилировать ПО, чтобы его избегать. Другими словами, все обязаны компилировать и проверять своё ПО ещё раз в процессе сборки пакета. Видимо об этом речь. big_smile

40 (2018-12-08 12:44:40 отредактировано alex_q_2000)

gaurii⇓ пишет:

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

Здравствуйте, gaurii yikes
Разбирая на запчасти пакет 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)

Что означает такая форма записи при определении зависимостей в спеке и где об этом можно почитать?

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

41

alex_q_2000 пишет:
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 попробовать.
Я только писал:

alex_q_2000 пишет:
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

Mageia 9b2
openSUSE 15.4
Спасибо сказали: alex_q_20001

42 (2018-12-10 10:39:34 отредактировано alex_q_2000)

gaurii⇓ пишет:

В спеках надо писать 'pkgconfig(QtWebKit)'! Господа, неужели это так сложно - сделать 'urpmq --provides devel-пакет' и выбрать из списка правильную строку, которая не будет зависеть от архитектуры? Например QtWebKit предлагает два таких варианта: qtwebkit-devel и pkgconfig(QtWebKit). Предпочтение следует отдавать варианту с pkgconfig (если он есть).

Огроменное спасибо, gaurii! И olelukoie...

Провел эксперимент на "зондирование" этих "обтекаемых" описаний зависимостей devel-пакетов:
urpmq --provides lib64mpv-devel

Spoiler

lib64mpv-devel: devel(libmpv(64bit))
lib64mpv-devel: lib64mpv-devel[== 0.25.0-2.mga6]
lib64mpv-devel: lib64mpv-devel(x86-64)[== 0.25.0-2.mga6]
lib64mpv-devel: mpv-devel[== 0.25.0-2.mga6]
lib64mpv-devel: pkgconfig(mpv)[== 1.24.0]
lib64mpv-devel: devel(libmpv(64bit))
lib64mpv-devel: lib64mpv-devel[== 0.27.0-2.mga6]
lib64mpv-devel: lib64mpv-devel(x86-64)[== 0.27.0-2.mga6]
lib64mpv-devel: mpv-devel[== 0.27.0-2.mga6]
lib64mpv-devel: pkgconfig(mpv)[== 1.25.0]
lib64mpv-devel: devel(libmpv(64bit))
lib64mpv-devel: lib64mpv-devel[== 0.27.0-3.mga6]
lib64mpv-devel: lib64mpv-devel(x86-64)[== 0.27.0-3.mga6]
lib64mpv-devel: mpv-devel[== 0.27.0-3.mga6]
lib64mpv-devel: pkgconfig(mpv)[== 1.25.0]
lib64mpv-devel: devel(libmpv(64bit))
lib64mpv-devel: lib64mpv-devel[== 0.27.2-1.mga6]
lib64mpv-devel: lib64mpv-devel(x86-64)[== 0.27.2-1.mga6]
lib64mpv-devel: mpv-devel[== 0.27.2-1.mga6]
lib64mpv-devel: pkgconfig(mpv)[== 1.25.0]

Увидел, что автоматическую установку lib64mpv-devel или libmpv-devel без указания архитектуры можно "описать" несколькими способами:

mpv-devel
pkgconfig(mpv)

Предпочтительный способ:

Requires: pkgconfig(mpv)

И проверил в реале:

urpmi mpv-devel
или
urpmi "pkgconfig(mpv)"

Здесь копия из wiki по Fedora, чтобы не спёрли:

Spoiler

BuildRequires: pkgconfig(foo) vs. foo-devel

Fedora packages which use pkg-config to build against a library (e.g. 'foo') on which they depend, SHOULD express their build dependency correctly as pkgconfig(foo).

The build infrastructure for a given package will often locate and use required libraries by using pkg-config.
Thus, pkgconfig(foo) is the true statement of the build dependency, and is how it should be expressed in the spec file.

For historical reasons, many packages seem to have a hard-coded "BuildRequires: foo-devel", with the name of the package which currently provides the required pkgconfig module. This is fragile and less portable than simply expressing the real dependency. Where package names change, and/or a required pkgconfig module is later provided by a different package, these hard-coded dependencies break.

Note that it shall still be acceptable to require specific packages by name if they are required for some reason other than a pkg-config module that they provide.

Example

Packages which build against libproxy should contain the following:
BuildRequires: pkgconfig(libproxy-1.0)

... and not the following:

BuildRequires: libproxy-devel

This way, if the libproxy-1.0.pc pkgconfig module is ever provided from a differently-named package (such as by PacRunner once its integration is complete, or by a 'libproxy1' backward-compatibility package as has happened to a number of other libraries in the past), the dependency will continue to be correct.

Вывод: Это мега-очешуенно, gaurii!!! Теперь ZVVOnlineTV можно сделать "бесполым" (noarch). yikes
UPD: Дополнительно, Provides описаны для каждого пакета на pkgs.org.

43

gaurii⇓ пишет:

Опять же...

Здравствуйте, gaurii. smile
Если у Вас есть время, подскажите пожалуйста по этим вопросам...
1. Когда я собираю lib-пакет из библиотек *.so, rpmbuild сам создаёт симлинки, которые так же приходится добавлять в rpm. Это нормально?
2. В Винде dll можно закинуть прямо в папку с программой и распространять. А в Linux можно *.so запихивать прямо в пакет с программой, что бы их по системе "не размазывать"? Или так нельзя?

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

44

Симлинки создаются потому, что программы требуют библиотеку определённой мажорной версии. А минорная версия может быть в разных дистрибутивах разная, может поменяться после обновления и т.п. Поэтому создаётся симлинк с номером мажорной версии, который указывает на собственно библиотеку. Если взять для примера нашу libmpv1, то в пакете версии 0.25 симлинк libmpv.so.1 указывает на libmpv.so.1.24.0 , а в версии 0.27 на libmpv.so.1.25.0. Если нашей проге нужна библиотека libmpv1, она её найдёт по ссылке, независимо от номера минорной версии. Это нормально и правильно.
Видимо, есть гайдлайны для разработчиков дистрибутивов, которые предписывают паковать библиотеки в отдельные пакеты. Это лучше у Алекса спросить, можно или нельзя паковать вместе.

Mageia 9b2
openSUSE 15.4
Спасибо сказали: alex_q_20001

45

Можно, но виндовый способ не приветствуется.

Разработчик, мейнтейнер, переводчик, по всем вопросам.
Спасибо сказали: alex_q_20001

46

Лучше чтобы каждая отдельная единица была в своём пакете. Т.е. если библиотека просто библиотека, то чтобы она была в своём отдельном пакете. Тогда будет проще обновлять систему.

Другой вопрос, что в наиболее популярных дистрибутивах даже одну отдельную единицу могут покрошить на множество мелких пакетиков. В т.ч. пакет библиотеки разобрать как минимум на два пакета: первый с бинарником библиотеки, а второй - -dev или -devel - с заголовочными файлами и прочими файлами для разработки на основе этой библиотеки. К такому тоже можно относиться по-разному, и, например, в тех же дистрибутивах Slackware и Arch/Manjaro так не принято. Там любят крупные пакеты. В т.ч. если библиотека не сама по себе, а идёт в составе какой-либо программы, то она вполне может оказаться целиком и полностью в пакете с этой программой.

Mageia 8 x86_64 / FVWM
Спасибо сказали: alex_q_20001

47

AlexL⇓ пишет:

Можно, но виндовый способ не приветствуется.

Здравствуйте, 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 /папка/с/либами?

Спасибо. smile

48

Ничего не нужно. Вообще.

Разработчик, мейнтейнер, переводчик, по всем вопросам.
Спасибо сказали: alex_q_20001

49 (2018-12-29 17:58:15 отредактировано alex_q_2000)

saahriktu⇓ пишет:

Лучше чтобы каждая отдельная единица была в своём пакете.

Здравствуйте, saahriktu.
Пока gaurii и AlexL от меня отдыхают, решил вопрос задать Вам, на примере т.с. yikes

Вот, на гит-хабе имеется программа qjournalctl:
master-версия с исправлениями месячной давности: https://github.com/pentix/qjournalctl
И release v0.5.1, датированная февралём этого года: https://github.com/pentix/qjournalctl/releases

Вопрос: Если я надумал всё это (или другое) добро скомпилить/опакетить, следует отдать предпочтение master-у или release?

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

50

alex_q_2000, Мартин, автор mseide, msegui, mselang выпустил релиз, после этого внёс исправления в master и умер. На чём основывать сборку пакета? Конечно, на master. То есть на исправленной версии. Но Мартин был бриллиантом, у него любой срез стабилен, ничего не ломал при фиксах. А у других master может быть хуже релиза.

Разработчик, мейнтейнер, переводчик, по всем вопросам.
Спасибо сказали: alex_q_20001