Реализация .PFS (тестирование)

[Zay]

Сейчас надо разработать механизм, который позволит всё делать локально.
А куда и как выкладывать - разберёмся потом.

[sfs]

Локально вся репа есть только у Pro. Тогда надо у него спросить что не хватает и насколько удобно сгенерить libs.lst. Выложит - можно будет заниматься pfs.depends

[Pro]

Выложит - можно будет заниматься pfs.depends

куда?

-----------------------
Давайте обозначим этапы на которых нужна проверка зависимостей:
1. При создании пакета - формируется файл depends без проверки наличия нужного в системе.
2. При объединении пакетов (pfsmerge) - проверяются ........ я запутался вобщем.

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

[sfs]

куда?

ftp://mirror.yandex.ru/puppyrus/pfs/packages-base/
В репу. Считаю, что до решения http://forum.puppyrus.org/index.php/topic,13532.0.html зависимостями заниматься рано

[RoDoN]

Система PR-13.01 и проблема такая, что если щелкнуть на .pfs модуль, который автоматически подключен при загрузке или на модуле с таким же именем, то предлагается его отключить и если случайно (или не случайно) согласился, то чаще всего этот процесс зависает, висит окошко "Идет отключение" и не отключается никак. Остальные проги работают нормально, но больше до ребута системы не получается ни подключить, ни отключить др. модули .pfs.
Можно ли как-то вообще запретить отключение автомат. подключенных при загрузке модулей?

[sfs]

если щелкнуть на .pfs модуль, который автоматически подключен при загрузке или на модуле с таким же именем, то предлагается его отключить и если случайно (или не случайно) согласился, то чаще всего этот процесс зависает, висит окошко "Идет отключение" и не отключается никак.

Тоже сталкивался. При этом если cделать losetup или df- конца процесса не дождаться

[Pro]

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

[Zay]

если щелкнуть на .pfs модуль, который автоматически подключен при загрузке или на модуле с таким же именем, то предлагается его отключить

С точки зрения скрипта нет разницы, подключён модуль при загрузке или потом.

и если случайно (или не случайно) согласился, то чаще всего этот процесс зависает, висит окошко "Идет отключение" и не отключается никак

Системная проблема.

При этом если cделать losetup или df- конца процесса не дождаться

Похоже что скрипты зависают на запуске losetup-FULL.

Скорее всего дело не в подключении пакетов при загрузке, а в том что файлы из этих пакетов используются.
Как это исправить - не знаю...

[Zay]

При создании пакета - формируется файл depends без проверки наличия нужного в системе.

Вот это нужно.
Все проверки потом (при подключении, сборке и т.д.) будут на основе содержимого pfs.depends.
Проверка наличия пакетов-зависимостей при подключении уже реализована в open_pfs.

[sfs]

Скорее всего дело не в подключении пакетов при загрузке, а в том что файлы из этих пакетов используются.

Может быть проблема возникает только при подключении поверх и потом отключении модуля из середины. У меня такое впечатление создавалось.

[RoDoN]

Можно ли как-то вообще запретить отключение автомат. подключенных при загрузке модулей?

До решения проблемы для себя временно сделал так, в файле /usr/sbin/open_pfs в строки 291-299:

Код

  # Файл с таким названием подключен:
  
    export_DIALOG_QUECTION " Отключение PFS " " Пакет <b>$(basename "${pack}")</b> подключен.${IFS} Отключить его сейчас?"
    eval "`gtkdialog3 --program=DIALOG_QUECTION --center`"

    if [ "$EXIT" = "Yes" ]; then  
      export_DIALOG_INFO " Отключение... " " Отключение пакета... "
      gtkdialog3 --program=DIALOG_INFO --center &
      dlgwait=$!

добавил проверку попытки отключения автоматически подключенных при загрузке модулей:

Код

  # Файл с таким названием подключен:
  
    export_DIALOG_QUECTION " Отключение PFS " " Пакет <b>$(basename "${pack}")</b> подключен.${IFS} Отключить его сейчас?"
    eval "`gtkdialog3 --program=DIALOG_QUECTION --center`"

    if [ "$EXIT" = "Yes" ]; then  
	if [ "$(grep $(basename "${pack}") /tmp/permanent_pfs_load.log)" != "" ]; then
		export_DIALOG_ERROR " Ошибка! " " ОШИБКА! Пакет <b>$(basename "${pack}")</b> был автоматически подключен при загрузке. Отключение невозможно! "
		gtkdialog3 --program=DIALOG_ERROR --center &
		exit
   	fi
      export_DIALOG_INFO " Отключение... " " Отключение пакета... "
      gtkdialog3 --program=DIALOG_INFO --center &
      dlgwait=$!

Теперь висяков нет. Жду других вариантов решения проблемы.

[sfs]

До решения проблемы для себя временно сделал так

Т.е. вариантов починить нет - только запретить?

[Pro]

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

[RoDoN]

Проверка, которую я добавил как раз это и делает, т.е. при совпадении имен предлагается отключить, как и было раньше, но если модуль с таким именем был автоподключен, то не дает отключить. Можно эту проверку поставить чуть раньше и тогда предложения на отключение не будет, а будет сообщение, что такой модуль автоподключен и отключ. не возможно.

[Zay]

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

Тут есть сложности.
Например, если модуль подключён с копированием в RAM - то это тот же случай, когда "фактически не подключен, но совпадает по названию с подключенным".

С самого начала работы над скриптами было решено, что подключение двух модулей с одинаковыми названиями недопустимо, эта логика присутствует во многих скриптах.
Можно конечно сделать по примеру RoDoN'а, но это не решение проблемы (наверняка такие ошибки могут происходить не только с автоподключаемыми модулями).

При попытке отключить используемый модуль скрипт pfsunload должен вернуть ошибку и завершить работу (не отключая модуль). В некоторых случаях так и происходит.
Вопрос - почему в других случаях вместо ошибки размонтирования происходит зависание?!