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

[Pro]

насчет вопроса незнаю пока что.

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

[Zay]

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

Если, например, пакет был подключён с копированием в RAM - то в каком каталоге он был уже не узнать.
А смонтировать два пакета с одинаковыми названиями и раньше было невозможно, и сейчас.

[Zay]

Пакет обновлён.
Принципиальных изменений нет, в основном мелкие исправления и дополнения.

В скрипты mkpfs и pfsmerge добавлена поддержка параметра -processors (передаётся mksquashfs).

Добавлен экспериментальный скрипт unpfs (распаковка пакета в каталог).
Использование: unpfs /file.pfs /catalog -p pack1

Изменения в документацию будут внесены позже.

[KOT]

Читал-читал и не понял, а зачем отключать автоподключенные пакеты, у меня грузится автоматически  usoft-pro-13.01.pfs и скажите зачем его надо отключать?   Или зачем отключать xorg или icewm или вообще базовый?

[Pro]

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

[sfs]

Использование: unpfs /file.pfs /catalog -p pack1

Чем это лучше unsquashfs -d  ? И что такое -p pack1 ?

В скрипты mkpfs и pfsmerge добавлена поддержка параметра -processors

Тогда и Decompressors available: gzip lzo xz и  -comp xz -Xbcj x86 не помешает

не понял, а зачем отключать автоподключенные пакеты

Отключение .pfs подключенных без копирования в RAM даст только проблемы в виде "хвостов"
Хвост : измененный файл подключенного модуля. Он уже в tmpfs или сохраненке и слои aufs ему безразличны. Т.е. подключай-отключай что хочешь - хвост останется неизменным.
Именно поэтому я всегда был и остаюсь  против подключения софта выше базы по умолчанию. Так хвостов будет больше.
Отключать имеет смысл RAM подключенные модули.
Практический пример: RAM подключаю devx и стремительно компилю что-то тоже на RAM диске. При этом экономлю ресурс флэшки\винта и батарею. Скомпилил - отключил devx - освободил память

[RoDoN]

Практический пример: RAM подключаю devx и...отключил devx - освободил память

А что ты devx подключаешь автоматически при загрузке? Я нет, только при необходимости, а потом отключаю и не обязательно делать это в RAM. Вопрос же был про автоподключенные пакеты, т.е. их зачем отключать.
Про "хвосты" согласен, что причина проблемы скорее всего в них.

[sfs]

devx подключаешь автоматически при загрузке? Я нет, только при необходимости, а потом отключаю и не обязательно делать это в RAM.

Нет. Автоподключать логично то что постоянно нужно. Так же никакой логики это отключать нет.
Теоретически загрузка в рэм дает скорость. Практически не так все просто: Запущенный бинарник будет загружен в рэм не зависимо от местонахождения (рэм\винт). Т.е. ускорение будет только при 1м старте. Ну и неоспоримое преимущество "в рэм" - загрузочный носитель можно отмонтировать
Подключенное без копирования в RAM вообще не вижу смысла отключать

[Zay]

Чем это лучше unsquashfs -d  ? И что такое -p pack1 ?

Извлекаются только файлы, из которых состоит пакет (без /etc/packages/mount и т.д.).
Ключ -p необязательный (позволяет извлечь не все пакеты, а только указанные, аналогично pfsextract).

Тогда и Decompressors available: gzip lzo xz и  -comp xz -Xbcj x86 не помешает

Это разные вещи.
Тип сжатия у пакетов .pfs один - xz. Это учитывается в нескольких скриптах. Конечно можно сделать файл .pfs со сжатием gzip, и он даже будет работать, но это уже будет нарушением спецификации.
Что касается -Xbcj x86 вопрос пока остаётся открытым. С одной стороны небольшая экономия места, с другой - теоретически возможная несовместимость (если я правильно понял).


Возможность отключения автоподключаемых пакетов нужна.
Например, если удалить подключённый (не через RAM) пакет - место на разделе, скорее всего, не освободится (т.е. его надо сначала отключить).

[Zay]

Вернёмся к теме о зависимостях (иначе автоматизации сборки не будет).

Вопрос к sfs, что именно выдаёт Ваш последний скрипт на выходе?
По идее нужно - список необходимых библиотек (кроме тех, что в каталоге уже есть).

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

[sfs]

Вернёмся к теме о зависимостях (иначе автоматизации сборки не будет).

А не наоборот? Что можно сделать без libs.lst?

что именно выдаёт Ваш последний скрипт на выходе?

Вроде это и выдает. Чуть изменив можно сделать : все , недостающие и т.п. Помню только что все выкладывал в эту тему.
Поясните что именно Вы хотите сделать...

[Zay]

Поясните что именно Вы хотите сделать...

Либо модифицировать скрипт mkpfs, либо сделать обёртку к нему.
Где именно искать зависимости (в libs.lst или ещё где-либо) - пока вопрос. Буду попробовать.

[sfs]

pfsextract
В распакованных модулях все права на файлы изменяются на root:root
Если работать под root - не критично. Но у нас, я так понял, есть планы на неroot.

модифицировать скрипт mkpfs, либо сделать обёртку к нему.

Предлагаю зависимости (в идеале бы и список файлов) привести к формату /var/lib/pacman/local/*/desc пакетов archlinux
У нас все то же самое (кроме сжатия). Надо ли изобретать. Совместимость в перспективе даст менее партизанское использование ABS и AUR, а может быть и возможность прикрутить pacman или хотя бы packer (в режиме "только aur")  или переделать spkg (sh скрипт из archpup) на .pfs.
На выходе можно получить решение всех наших проблем : обновление репы, зависимости, glibc и разборка на .pfs devx. А может и systemd

[Zay]

В распакованных модулях все права на файлы изменяются на root:root

В правах я не очень разбираюсь (привык работать из под root).
Есть конкретные предложения, что изменить в работе скриптов?

Предлагаю зависимости (в идеале бы и список файлов) привести к формату .PKGINFO пакетов archlinux

Нереально, ИМХО. Слишком много всего придётся переделать. Теряется простота и ясность формата PFS, а совместимости с чужими пакетами всё равно не будет.
Единственное, что можно сделать в этом направлении - изменить формат файла pfs.specs (он сейчас нигде не используется, но в будущем может быть полезно).

Что касается совместимости пакетов - её лучше реализовать в соотв. скриптах (по принципу pet2pfs и petinstall), т.е. на лету конвертировать пакеты в PFS-совместимый формат.

[sfs]

ок - pfsextract посмотрю
Список файлов - как в арче - пожалуй не так и актуально. Он нужен для удаления файлов pacman-ом. С этим pfs-util и сам справляется.

А вот /var/lib/pacman/local/*/desc - хорошо бы. Тогда есть перспектива прикрутить pacman и убедить его в том что наши pfs - это его родные пакеты. Что даст возможность использовать репу арча. Скачанные pacman-ом пакеты в /var/cache/pacman можно скриптом конвертировать в pfs
Можно вообще весь дистр таким образом (перепаковкой) пересобрать. Причем займет это день ,а не год.
А потом "долгими зимними вечерами" перекомпилять используя aur все что угодно как угодно.
Т.е не теряем ничего, а приобретаем много.
Нечто подобное я сделал. Только базу собирал pacman-ом, а остальное- pfs-util. Если интересует - могу выложить. Еще сыровато - но изложенные мной идеи вполне иллюстрирует + systemd. Pано или поздно на systemd переходить по любому придется.