Far2l packaging

[invy]

Prepare binary packages for popular distros.

As of now I could imagine following issues regarding packaging:

1. plugin location and changes to far so it could find plugins (evtl. configurable)
   • default plugins ( /use/lib/far2l/ )
   • custom plugins ( ~/.local/lib/far2l )
2. 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;
};

[lieff]

Я бы все стандартное оставил как есть сейчас в install, не вижу смысла раскидывать. Подход все статическое в одном месте у приложения мне больше нравится. А вот кастомные бы дополнительно бы грузил из ~/.local/ да, т.к. у юзера может не быть прав записи в установленный для всей системы.
Так же snap/flatpak/appimage было бы не плохо.

[invy]

В Linux нельзя все это сунуть в /use/bin, надо рпскидать по соответствующим директориям, потому нужна возможность все это дело грузить из стандартных системных директорий. Иначе просто нет шанса в апстрим фар отправить. А отправлять надо для популярности.

[lieff]

Ну минимально разбить придется да. Например все в /usr/lib/far а в bin только симлинк. Видел как многие так поступают.

[invy]

Не вижу проблемы разбить сразу по-человечески ;)

Что касается кастомных плагинов - только из ~/.local - мало ли какую гадость там понаписывают чтобы ее еще в систему пихать :)

[lieff]

По человечески понятие относительное ), например в GoboLinux как раз каждая программа в своем каталоге. Хотя по большому счету мне все равно как оно будет разбито, можно и как принято в конкретном дистре. Просто подход GoboLinux мне больше по душе.

Насчет кастомных плагинов полностью согласен.

[invy]

Так, ну с путями к плагинам я проблемы не вижу.

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

[unxed]

chrome вообще ставится в /opt/google/chrome, в /usr/bin кладется симлинк, и всем так ок.
в таком варианте собрать пакет можно было бы уже сейчас.
потом - уже улучшить, если кого-то не устроит такая схема.
остается проблема с пользовательскими плагинами, но пока всё равно ни одного нет.

[unxed]

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

[invy]

Попробуй раскидать содержимое директории install по /usr/bin, /usr/share, и т.п. и заставить его работать.

[elfmz]

Я так полагаю, нужно научиться размазываться по файловой системе, как это тут принято
Но это не везде. Вон в альтлинуксе похоже таких тараканов нет, и far2l там запаковали довольно давно, настолько давно что не помешало бы им проапдейтиться: http://www.sisyphus.ru/ru/srpm/far2l

[invy]

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

[elfmz]

А куда пихать такие вспомогательные вещи, как far2l_askpass, roots.sh? Вроде исполняемые же, но и в bin/sbin им не место

[invy]

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

скорее всего в '/usr/sbin'

[unxed]

если я правильно понимаю этот самый стандарт, bin от sbin отличается тем, что в bin, в отличие от sbin, кладется то, что должно работать в однопользовательском режиме. соответственно, для частей far2l - скорее /usr/bin, нет?

вспомогательные файлы (фактически, всё, кроме бинарников), как я понимаю, вполне принято класть в /var/lib. например, /var/lib/far2l

[elfmz]

Вобщем как показало маленькое исследование - все без зазрения совести ложат свои приватные скрипты в /etc/whatever/.. И самый известный из них - /etc/init.d
Так что куда совать roots.sh уже ясно
Осталось выяснить как принято в osx

[unxed]

вообще говоря, можно же собрать хоть с какой-нибудь схемой расположения по папкам, а если придумается более лучшая в будущем - изменить?

[elfmz]

"хоть с какой нибудь" - уже собрано..
Кстати в табличке на вики написано - /opt - Optional application software packages.[6]
Собственно, что не так? Зачем размазываться по ФС?

[elfmz]

продолжая маленькое исследование: mc свои *.sh и elf-скринсейвер (наверное) держит в /usr/lib/mc
это в принципе адекватный вариант:
исполняемый файл - /usr/bin/far2l
скрипты/плагины - в /usr/lib/far2l/
Все остальное - в /etc/far2l/

[unxed]

в альтлинуксе сборка 4198cd5 от 29 сентября.

по папкам там разложено так:
всё, кроме changelog и copyright - в /usr/lib/far2l
в /usr/bin - far2l - симлинк на /usr/lib/far2l/far2l
в /usr/share/doc/far2l - changelog и copyright

[invy]

Не, надо по-феншую все делать (rpm и deb).

[elfmz]

всегда можно было запускать из консоли, и всегда он туда мусорил.. раньше мусорил кстати гораздо больше)

[unxed]

кстати, shell-скрипты вполне себе принято класть в /usr/bin
примеры: add-remove-locales, apt-add-repository, debconf
во всяком случае, у меня на mint - так

[elfmz]

шелл скрипты общего назначения, которые могут понадобиться юзеру - не вопрос
но roots.sh, trash.sh - это по сути внутренности far2l. far2l_sudoapp - так вообще совсем внутренность (впрочем, от него легко избавиться, просто в ps станет менее понятно кто есть кто).

[unxed]

впрочем, в /usr/lib тоже:
find /usr/lib -name *.sh
выдает целый список.

просто в ps станет менее понятно кто есть кто

пусть лучше будет понятно)

PS: посмотрите последний коммент #131 - в любом случае, прежде, чем распространять пакеты, хорошо бы определиться с хранением временных файлов и настроек

[elfmz]

вроде, норм сейчас?
far2l: /usr/bin/far2l
far2l_sudoapp, far2l_askpass и бинарники плагинов - в /usr/lib/far2l
Все остальное - в /etc/far2l
Кроме того, можно по-старинке запускать, скопировав все в /opt/far2l

[cycleg]

Вот вариант для сборки DEB-пакета через CPack, со строки 71.

CMakeLists.txt

Пакет генерируется командой make package.

В таком виде с пакетом есть две проблемы:

1. Зависимости от других пакетов (CPACK_DEBIAN_PACKAGE_DEPENDS). Сейчас указаны почти от балды. Это надо пилить под реальные зависимости far и конкретные выпуски ОС.
2. Те символические ссылки, которые делаются сейчас через install(CODE. По уму их создание и удаление нужно поместить в соответствующие пакетные сценарии. Например, для DEB это будут "postinst" и "prerm".

Ну и нужно делать выбор генератора пакета в зависимости от целевой ОС. В этом сценарии такого нет: жестко прописан DEB, строки 114-119. Точнее, он добавляется в список генераторов, и всякое нужное генератору пакета задается только для DEB.

По идее, для сборки того же RPM достаточно задать те его параметры, которые не "выводятся" из общих (CPACK_PACKAGE_XXX), и добавить генератор RPM в список CPACK_GENERATOR. make package пытается запустить все генераторы из списка и построить все разновидности пакетов.

[invy]

@elfmz

Все остальное - в /etc/far2l

эм, все надо .hlf и .lng - в /usr/share/far2l, им точно не место в /etc, т.к. это не конфигурационные файлы.

[elfmz]

когда выбирал между /etc и /usr/share выбрал первый т.к. короче)
.lng в каком то смысле и конфиги.. вдруг захочется кастомизировать интерфейс)

[unxed]

ну во вьювере работает, правда не из менюшки, а непосредственно при открытии файла

А, хм, и прада работает при открытии и во вьювере и в редакторе. А вот из менюхи не работает почему-то.

[unxed]

почему там серенькая менюшка

Я честно думал, что это какой-то артефакт портирования, который не сочли нужным чинить, а UCD не выпиливается только потому что без него вообще сборка развалится)))

[elfmz]

да не, рабочая фича, а менюшка похоже просто не была заимплеменчена в форкнутых срыцах)

[elfmz]

вродь сделал менюху

[unxed]

вродь сделал менюху

потестил немножко. в целом работает :) забавно, она в состоянии задетектить "тест €" в UTF-8, но не в состоянии ту же строчку в 1251 (данных маловато для статанализа?). ещё не смогла задетектить "Тест" в utf16le. греческий не оч детектится, но это я и по unar знаю, который статанализ для зипов использует. это всё вопросики скорее к либе, чем к far2l, в любом случае.

но это мелочи. а вот что неприятно, это то, что при открытии вот этого тестового файлика кодировка детектится как UTF-8, и половина контента молча вырезается
mixed.txt

и ещё фейл детектинга определяется только по не-смене кодировки, это странно. можно мсгбокс кидать, типа, "не шмогла я!"

[elfmz]

это еще что, она не в состоянии задетектить самое русское слово из трех букв, написанное в CP1251

[unxed]

А они там в этой uchardet не очень-то жалуют OEM кодировки, как я погляжу. Для кириллицы есть, а вот с остальными языками не очень. Пожаловался им в багтрекер на греческий и иврит :))

[unxed]

Надо, наверное, в README прописать, что, мол, если ваша кодировка не детектится, то жаловаться надо сюда:
https://gitlab.freedesktop.org/uchardet/uchardet/-/issues

[elfmz]

ну прежде чем жаловаться надо проверить может проблема в отсутствии страницы в wine-овском коде)

[unxed]

Ну ок, тогда формулирвока будет «если ваша кодировка есть в списке по Shift-F8, Ctrl-H, но не автодетектится» :)
Вот с 737 и 862, на которых я экспериментировал — как раз так.

[unxed]

Вообще странно, что у них поддержка кодировок такая выборочная. По идее же статистические модели одни и те же для одного и того же языка, так что можно было бы все существующие для него кодировки поддерживать. Или, типа, больше кодировок в базе — больше ложных срабатываний? Ну тогда надо возвращать несколько вариантов и давать юзеру выбрать.

[elfmz]

Идеального нет, если греков набереться достаочно много, чтоб один из них открыл багу на эту тему, можно будет заморочиться. Но судя по отсутствию греческой локализации апстрима, это случится как минимум не скоро.

[unxed]

Идеального нет, если греков набереться достаочно много, чтоб один из них открыл багу на эту тему, можно будет заморочиться. Но судя по отсутствию греческой локализации апстрима, это случится как минимум не скоро.

Ну я одного грека, запарившегося с проблемами в .zip'ах, просветил вот что в far2l решены они :) А он для греческих школ софт в ppa собирает. Так что, может, юзеры оттуда и появятся))

btw, Ins/Del/F4 в Shift-F8 меню не работают.

[unxed]

Кстати, о штуках, которые есть в UI, но не работают. К бете хорошо бы убрать (ну, скрыть из UI, по крайней мере) те, что вряд ли в ближайшее время заработают. Чтоб не смущали юзера. #808

Ведь именно такие вещи и создают ощущение «сырой» софтины.

То есть, когда-нибудь запилить менеджер процессов и отключалку флешек было бы, конечно, классно. Но пока их нет, совершенно незачем в меню этим пунктам присутствовать и по Ctrl-W пустому списку показываться.

[unxed]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977790
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977807

https://mentors.debian.net/package/far2l/

[unxed]

@spvkgn предложение: собирать два отдельных пакета, far2l и far2l-gui, после того, как wx бэкэнд в отдельный .so вынесут. Можно будет удобно на сервера ставить без 300 мб ненужных там зависимостей

См. #912

[spvkgn]

@spvkgn предложение: собирать два отдельных пакета, far2l и far2l-gui, после того, как wx бэкэнд в отдельный .so вынесут. Можно будет удобно на сервера ставить без 300 мб ненужных там зависимостей

См. #912

Пока просто добавил другой ppa где собирается с -DUSEWX=no

https://launchpad.net/~far2l-team/+archive/ubuntu/far2l-tty

[Slach]

о, клево, спасибо ребята

[elfmz]

Начиная с 6a5e9b6 -DUSEWX=no и yes различаются только тем что с yes собирается /far2l_gui.so которая при инсталляции кладется в .../lib/far2l/
Так что действительно можно разделить на far2l-base и 'аддон' к нему far2l-gui, который содержит указанную so-шку и зависимость на far2l-base (и на wxWidgets).

[unxed]

Начиная с 6a5e9b6...

Same in English, for whose who are working on packages for different distros.

Starting with 6a5e9b6 GUI stuff is built into far2l_gui.so, which is not mandatory, but makes desktop experience better. This .so should probably be packaged into a separate package (which may be called far2l-wx or far2l-gui), and it should depend on main package (which may be called far2l-base).

This separation will help to avoid unneeded wx/X11 dependencies on headless servers, still allowing to install desktop version which has some advantages with a single apt-get command.

[elfmz]

Since 126a52b new binary and optional dependency added.
Binary: ../lib/far2l/far2l_ttyx.broker Dependency - libx11 - required only for this binary. Binary is being build automatically if cmake could find X11 during configuring, otherwise binary is not built. This binary extends far2l running in 'usual' TTY mode with access to host clipboard via X11 extensions if they're available and it can be installed separately i.e. can be kind of 'addon' package.

[alexmyczko]

This is happening at #692

[unxed]

@spvkgn а по какому расписанию работает сборка в ppa? То есть сколько времени проходит от коммита до обновления пакета?

[spvkgn]

@unxed в ppa включен daily build, т.е запускается раз в сутки, если есть изменения.

[jinek]

So is it distributed anywhere? Or may be package artifact can be downloaded?

[alexmyczko]

I have my packaging here: http://sid.ethz.ch/debian/far2l/

and the plan is to get it into the next debian stable release (freeze in January 2023)

a bit too late but it is now there. requests for backports are possible: https://backports.debian.org/Contribute/

[unxed]

1st Ubuntu with far2l on board! 🎉
https://releases.ubuntu.com/mantic/