elfmz
Far2l packaging
Prepare binary packages for popular distros.
As of now I could imagine following issues regarding packaging:
- plugin location and changes to far so it could find plugins (evtl. configurable)
- default plugins ( /use/lib/far2l/ )
- custom plugins ( ~/.local/lib/far2l )
- languages and help location and paths
- /usr/share/far2l
Plugin paths are configurable via
struct LoadPluginsOptions
{
// DWORD TypeLoadPlugins; // see TYPELOADPLUGINSOPTIONS
int MainPluginDir; // TRUE - использовать стандартный путь к основным плагинам
int PluginsCacheOnly; // seting by '/co' switch, not saved in registry
int PluginsPersonal;
FARString strCustomPluginsPath; // путь для поиска плагинов, указанный в /p
FARString strPersonalPluginsPath;
int SilentLoadPlugin; // при загрузке плагина с кривым...
int OEMPluginsSupport;
int ScanSymlinks;
};
Я бы все стандартное оставил как есть сейчас в install, не вижу смысла раскидывать. Подход все статическое в одном месте у приложения мне больше нравится. А вот кастомные бы дополнительно бы грузил из ~/.local/ да, т.к. у юзера может не быть прав записи в установленный для всей системы. Так же snap/flatpak/appimage было бы не плохо.
В Linux нельзя все это сунуть в /use/bin, надо рпскидать по соответствующим директориям, потому нужна возможность все это дело грузить из стандартных системных директорий. Иначе просто нет шанса в апстрим фар отправить. А отправлять надо для популярности.
Ну минимально разбить придется да. Например все в /usr/lib/far а в bin только симлинк. Видел как многие так поступают.
Не вижу проблемы разбить сразу по-человечески ;)
Что касается кастомных плагинов - только из ~/.local - мало ли какую гадость там понаписывают чтобы ее еще в систему пихать :)
По человечески понятие относительное ), например в GoboLinux как раз каждая программа в своем каталоге. Хотя по большому счету мне все равно как оно будет разбито, можно и как принято в конкретном дистре. Просто подход GoboLinux мне больше по душе.
Насчет кастомных плагинов полностью согласен.
Так, ну с путями к плагинам я проблемы не вижу.
struct LoadPluginsOptions
{
// DWORD TypeLoadPlugins; // see TYPELOADPLUGINSOPTIONS
int MainPluginDir; // TRUE - использовать стандартный путь к основным плагинам
int PluginsCacheOnly; // seting by '/co' switch, not saved in registry
int PluginsPersonal;
FARString strCustomPluginsPath; // путь для поиска плагинов, указанный в /p
FARString strPersonalPluginsPath;
int SilentLoadPlugin; // при загрузке плагина с кривым...
int OEMPluginsSupport;
int ScanSymlinks;
};
chrome вообще ставится в /opt/google/chrome, в /usr/bin кладется симлинк, и всем так ок. в таком варианте собрать пакет можно было бы уже сейчас. потом - уже улучшить, если кого-то не устроит такая схема. остается проблема с пользовательскими плагинами, но пока всё равно ни одного нет.
а всё-таки, что конкретно на данный момент мешает собрать пакеты? если ничего - могу попробовать сделать deb, повод научиться это делать.
Попробуй раскидать содержимое директории install по /usr/bin, /usr/share, и т.п. и заставить его работать.
Я так полагаю, нужно научиться размазываться по файловой системе, как это тут принято Но это не везде. Вон в альтлинуксе похоже таких тараканов нет, и far2l там запаковали довольно давно, настолько давно что не помешало бы им проапдейтиться: http://www.sisyphus.ru/ru/srpm/far2l
Ну это не тараканы а стандарт и без его соблюдения - в репозитории нет шансов попасть.
А куда пихать такие вспомогательные вещи, как far2l_askpass, roots.sh? Вроде исполняемые же, но и в bin/sbin им не место
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
скорее всего в '/usr/sbin'
если я правильно понимаю этот самый стандарт, bin от sbin отличается тем, что в bin, в отличие от sbin, кладется то, что должно работать в однопользовательском режиме. соответственно, для частей far2l - скорее /usr/bin, нет?
вспомогательные файлы (фактически, всё, кроме бинарников), как я понимаю, вполне принято класть в /var/lib. например, /var/lib/far2l
Вобщем как показало маленькое исследование - все без зазрения совести ложат свои приватные скрипты в /etc/whatever/.. И самый известный из них - /etc/init.d Так что куда совать roots.sh уже ясно Осталось выяснить как принято в osx
вообще говоря, можно же собрать хоть с какой-нибудь схемой расположения по папкам, а если придумается более лучшая в будущем - изменить?
"хоть с какой нибудь" - уже собрано.. Кстати в табличке на вики написано - /opt - Optional application software packages.[6] Собственно, что не так? Зачем размазываться по ФС?
продолжая маленькое исследование: mc свои *.sh и elf-скринсейвер (наверное) держит в /usr/lib/mc это в принципе адекватный вариант: исполняемый файл - /usr/bin/far2l скрипты/плагины - в /usr/lib/far2l/ Все остальное - в /etc/far2l/
в альтлинуксе сборка 4198cd5 от 29 сентября.
по папкам там разложено так: всё, кроме changelog и copyright - в /usr/lib/far2l в /usr/bin - far2l - симлинк на /usr/lib/far2l/far2l в /usr/share/doc/far2l - changelog и copyright
всегда можно было запускать из консоли, и всегда он туда мусорил.. раньше мусорил кстати гораздо больше)
кстати, shell-скрипты вполне себе принято класть в /usr/bin примеры: add-remove-locales, apt-add-repository, debconf во всяком случае, у меня на mint - так
шелл скрипты общего назначения, которые могут понадобиться юзеру - не вопрос но roots.sh, trash.sh - это по сути внутренности far2l. far2l_sudoapp - так вообще совсем внутренность (впрочем, от него легко избавиться, просто в ps станет менее понятно кто есть кто).
впрочем, в /usr/lib тоже:
find /usr/lib -name *.sh
выдает целый список.
просто в ps станет менее понятно кто есть кто
пусть лучше будет понятно)
PS: посмотрите последний коммент #131 - в любом случае, прежде, чем распространять пакеты, хорошо бы определиться с хранением временных файлов и настроек
вроде, норм сейчас? far2l: /usr/bin/far2l far2l_sudoapp, far2l_askpass и бинарники плагинов - в /usr/lib/far2l Все остальное - в /etc/far2l Кроме того, можно по-старинке запускать, скопировав все в /opt/far2l
Вот вариант для сборки DEB-пакета через CPack, со строки 71.
Пакет генерируется командой make package.
В таком виде с пакетом есть две проблемы:
- Зависимости от других пакетов (CPACK_DEBIAN_PACKAGE_DEPENDS). Сейчас указаны почти от балды. Это надо пилить под реальные зависимости far и конкретные выпуски ОС.
- Те символические ссылки, которые делаются сейчас через
install(CODE. По уму их создание и удаление нужно поместить в соответствующие пакетные сценарии. Например, для DEB это будут "postinst" и "prerm".
Ну и нужно делать выбор генератора пакета в зависимости от целевой ОС. В этом сценарии такого нет: жестко прописан DEB, строки 114-119. Точнее, он добавляется в список генераторов, и всякое нужное генератору пакета задается только для DEB.
По идее, для сборки того же RPM достаточно задать те его параметры, которые не "выводятся" из общих (CPACK_PACKAGE_XXX), и добавить генератор RPM в список CPACK_GENERATOR. make package пытается запустить все генераторы из списка и построить все разновидности пакетов.
@elfmz
Все остальное - в /etc/far2l
эм, все надо .hlf и .lng - в /usr/share/far2l, им точно не место в /etc, т.к. это не конфигурационные файлы.
когда выбирал между /etc и /usr/share выбрал первый т.к. короче) .lng в каком то смысле и конфиги.. вдруг захочется кастомизировать интерфейс)
ну .hlf уж точно не конфигурационные :) если уж размазываться по ФС "как тут принято", то красиво и логично :)