PFS-utils на github

[sfs]

Поэтому лучше вот модуль с тем, что более-менее проверено.

Да. В таком варианте шансов что кто-то протестирует больше

в fixmenus я придумал извращенческий метод перезапуска xfce4-panel

Да. Панель дергаться перестала, но в обычном меню появляется с опозданием
И при отключении - см аттач и из меню не убирается. Тут явно что-то не то. Этот текст я для пупи делал - там есть такая проблема

[ander]

Что интересно, эта ошибка при отключении возникает при использовании sfs-get, а из командной строки отключается нормально.
Попробую понять, в чем разница.
UPD
Да,малость накосячил.  pfsunload выходит со статусом 1, просто как результат последней проверки, что модуль не в ram и чистить не надо.  Поправил.

[sfs]

Да. Теперь все ок и xfce при обновлении дергается меньше.
Надо еще потестить и добавлю в сдедующий 089

[ander]

Кстати.
Поэкспериментировал с fixmenus (все в pra512g xfce).
В принципе, для обновления меню вполне достаточно дергать только xfdesktop
Вот только при этом то меню, что по правой кнопке мыши на десктопе обновляется сразу, а вот whiskermenu - только через одну-две минуты.  Вот и приходится дергать еще и панель, чтобы обновилось сразу 

[sfs]

C меню xfce тоже имел такие наблюдения
Еще notifyd иногда подглючивает с wt - сообщения остаются висеть. Тоже не знаю как улучшить

[neobht]

Я думаю функционал обновления меню не должен находится в pfs-utils.

[ander]

В принципе,конечно, не должен.  Он и находится в отдельном скрипте fixmenus.
Точно так же обновления всяческих mime-типов, кешей шрифтов и т.п. вынесены в pfs-update-caches.
Но поскольку эти файлы из pfsload/pfsunload вызываются, то пусть пока будут рядом, хотя бы в качестве примеров.
В конечном же итоге, разумеется, fixmenus самое место где-нибудь в пакете с оконным менеджером, причем у каждого менеджера и обновляться меню может по-своему, так что и файлы будут разные.

[sfs]

в pfs-update-caches про модули ядра не забыли? И вообще - в чем по замыслу отличие pfs-update-caches и в update-cache?

[ander]

в pfs-update-caches про модули ядра не забыли? И вообще - в чем по замыслу отличие pfs-update-caches и в update-cache?

Отличие только в том, что update-cache проверяет все сразу, и если хоть один пакет содержит что-то, требующее обновления - обновляет.
pfs-update-caches запускается при горячем подключении/отключении каждого пакета, соответственно, если подряд подключить их несколько, то и апдейт может быть вызван не один раз.

Модули ядра не включал.  depmod - тяжелая операция, будут тормоза.  Надо один раз собрать все модули ядра в кучу, запустить depmod и результаты его работы положить в базу - после этого modprobe будет работать почти на всех модулях ядра и depmod запускать не потребуется. Не пройдет такой метод только с проприетарными драйверами nvidia, потому что там для разных моделей карт модули ядра называются одинаково.  Но драйвера nvidia на горячую вроде бы не подключают, а если подключают, то и depmod надо делать из start.sh пакета.
Грузить модули ядра при подключении пакета - можно и вставить, но вот нужно ли?  Чего им память зря занимать, если использующее их приложение не запускается?  Может лучше, если нужны они, скажем, виртуалбоксу, так пусть он их и грузит при своем старте при помощи какой-нибудь обертки?

[sfs]

С проприетарными дровами тяжело. Не дождаться чтобы протестировали
Ок. пусть  будет как сейчас
vbox так и делает и там работает insmod
Поправил в update-cache - иконки и тп. не ищутся только в 001 модуле
Было в 0*

[ander]

А как их протестируешь, если у меня intel 

[sfs]

Вот в этом и проблема, что 5 разных видях ни у кого нет 

[Zay]

Смысла нет, зато есть наглядность, всё в одном окне.

Ну так и я за стандарт!
Только не надо тогда никаких --nh и вариантов путей монтирования.
Думаю что самое правильное - это /etc/profile или что-то подобное.
И pfsload должен выбирать точку монтирования всегда однозначно.

Сейчас initrd монтирует базовые модули в /initrd/pup_rw, /initrd/pup_ro1+wh, /initrd/pup_ro2, /initrd/pup_z при любом их сочетании кроме отсутствия самой базы и от замены абстрактных pup_ro2 и pup_z на понятные base и kernel ничего не изменится.

pup_ro2 и pup_z давно не нужны. Все PFS лучше монтировать одинаково.

Я думаю функционал обновления меню не должен находится в pfs-utils.

Тоже так думаю.
Кстати, всяким *_nomenu тоже не место в основном пакете, они только в PuppyRus нужны.

PFS-utils достаточно проверять наличие скрипта fixmenus в системе, если он есть - вызывать.
А сам скрипт должен быть в каждом дистрибутиве свой. Тоже самое и с сообщениями notify.

[sfs]

Сейчас notify встроен и это плохо

[Zay]

Сейчас notify встроен и это плохо

Согласен. Но вынести его будет не сложно, было бы время и желание.