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

[Zay]

Отлично! Про -Xbcj x86 всё ясно, совместимость не теряется.
Будет включено по умолчанию в след. версию.

От поддержки %FILES%, я думаю, хуже не будет. Ну а использовать её, или нет - можно потом подумать.

[sfs]

Тогда уж -b 256K -Xbcj x86 - так сейчас в PRA
или даже 512 как MagOsовцы советовали

От поддержки %FILES%, я думаю, хуже не будет. Ну а использовать её, или нет - можно потом подумать.

Если не долго и не сложно - не помешает
тогда смогу делать симлинк из /etc/packages/../..files в /var/lib/pacman

[Zay]

Обновление!

Исправление ошибки при сборке / разборке / установке пакетов, при наличии в них каталогов или файлов с символом "\" названии.
(Описание проблемы: http://forum.puppyrus.org/index.php/topic,12727.msg80100.html#msg80100).

При сжатии пакетов по умолчанию используются параметры mksquashfs -comp xz -b 512K -Xbcj x86.

Поддержка нестандартных списков файлов в pfs.depends (при чтении списков все символы до первого "/" отбрасываются).


Код создания списка зависимостей вынесен из mkpfs в отдельные скрипты:
lddcheck /catalog - выводит список библиотек, на которые ссылаются все исполняемые файлы, находящиеся в этом каталоге.
pfsfindlibs /catalog - выводит список зависимостей, т.е. пакетов, содержащих необходимые библиотеки. С параметром -s / --short выводит сокращенные названия пакетов (без номеров версий программ).

Создать файл со списком зависимостей можно командой:
  pfsfindlibs -s /path/PACKAGE >/path/PACKAGE/etc/packages/mount/PACKAGE/pfs.depends

Перед сборкой пакета (mkpfs) можно исправить или дополнить список вручную.

При создании списка зависимостей все пакеты с необходимыми библиотеками должны присутствовать в системе.
Если часть библиотек не будет найдена в списках файлов подключённых/установленных пакетов будет выведено предупреждение.


Скрипты pfsfindlibs и lddcheck очень желательно протестировать!!! Особенно в PuppyRus.

[Pro]

спасибо, думаю протестирую на пакете evince, он зараза компилируется под конкретную версию poppler.

[sfs]

Не глядя + за возобновление (очень надеюсь) работ
lddcheck - Дядя Шурик мне подогнал волшебную строку. До этого у меня был самопальный многопроходный скрипт
Я уже обкатал строку Дяди Шурика - все ок. Рекомендую. $1- папка, где искать

Код

find "$1" -type f -executable -exec ldd {} \; |awk '/=> not found/ {print $1}'|sort -u 

Упоминание pfs.depends - текстовым поиском нашел только в pfsdepends
Т.е. скрипты почищены от старой реализации и пытаемся сделать новую? Тогда давайте определимся - что хотим получить в итоге и под какой дистр
Имею опыт применения pfs-utils в различных не пупи - очень помогает. Надо бы держаться универсальности

Сборка в стиле ПМ с полным разбором зависимостей актуальна только в PR. Причем для этого надо будет создавать базу файлов всей репы.
Предлагаю подобный код (если кто-то впишется) делать отдельными скриптами - как и начал Zay в последней версии

Про остальное хочется совсем простого и универсального:
1. В пакете прописаны зависимости (перечислены нужные .pfs). Создание этого - отдельным скриптом или руками
2. Скрипт скачки и подключения по этому списку.

В sfs-get у меня это реализовано. Не идеально. Многовато исторических наслоений. Поэтому, возможно, не повредит переписать заново, использовав часть кода. Сейчас выложу вчерашнюю версию
На уровне идеи нормально получилась работа с репами с различным размещением (ftp\www\url)
Разбор зависимостей работает, но удобства мало. Тут надо думать...

[sfs]

pfsextract баг с правами:
1. pfsmerge home.pfs 2.pfs out.pfs , где в home.pfs есть права на файлы не root. В out.pfs все ок
2. pfsextract out.pfs : в home.pfs пропали права. Везде root

В 1й раз воткнул 0.3.5 в PRA без доработок. Пока Ок. Баг выше старый. Все сформулировать не мог
Пришлось перепаковать, т.к. в арче нет sbin. Иначе убъет систему. Нельзя ли в следующих версиях все положить в bin ?

[Zay]

По зависимостям сейчас в PFS-utils ситуация следующая.

Информация о необходимых пакетах хранится в файле pfs.depends.
Формат файла - построчный список пакетов. В случае когда возможны альтернативы, они перечисляются через "/" в одной строке. Допустимы сокращённые названия.

Получить информацию об отсутствующих зависимостях можно с помощью скрипта pfsdepends.
pfsdepends (без параметров) - выводит список неудовлетворенных зависимостей всех подключённых / установленных пакетов в системе.
pfsdepends -f /file.pfs - выводит список неудовлетворенных зависимостей пакетов в указанном файле PFS.
Скрипт open_pfs при подключении пакета проверяет неудовлетворённые зависимости, и если они есть - показывает их список пользователю.

Автоматизация создания списка зависимостей:
Скрипт pfsfindlibs выводит список зависимостей в формате, совместимом с форматом pfs.depends (можно перенаправлять вывод скрипта в этот файл).
При необходимости список в файле pfs.depends, созданный скриптом pfsfindlibs можно исправить руками перед созданием пакета.
Или же создать файл pfs.depends с нуля и заполнить вручную (соблюдая формат).

Про остальное хочется совсем простого и универсального:
1. В пакете прописаны зависимости (перечислены нужные .pfs). Создание этого - отдельным скриптом или руками

Это уже есть, см. выше. Либо скриптом pfsfindlibs, либо руками.

2. Скрипт скачки и подключения по этому списку.

А вот этого пока нет, к сожалению...

Упоминание pfs.depends - текстовым поиском нашел только в pfsdepends
Т.е. скрипты почищены от старой реализации и пытаемся сделать новую?

Старая реализация как была, так и осталась.
Все скрипты, читающие файл pfs.depends, делают это не напрямую, а через обращение к скрипту pfsdepends. По принципу - не дублировать код.
Единственное, что изменилось - из mkpfs убрано всё, что имеет отношение к зависимостям (вынесено в отдельные скрипты).

Сборка в стиле ПМ с полным разбором зависимостей актуальна только в PR.

Это одна из задач разработки PFS-utils, в любом случае.

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

Нет, не надо. Достаточно при сборке пакетов создавать (автоматом или руками) корректный файл pfs.depends.

pfsextract баг с правами:
1. pfsmerge home.pfs 2.pfs out.pfs , где в home.pfs есть права на файлы не root. В out.pfs все ок
2. pfsextract out.pfs : в home.pfs пропали права. Везде root

Да, я помню про это, но как исправить - не знаю. Права не должны пропадать...
А если попробовать unpfs out.pfs -p home, что происходит с правами?

[Zay]

Pro, надо бы перенести скрипт topaufslayer (во вложении) из PFS-utils в скелетон.

Нельзя ли в следующих версиях все положить в bin ?

Это вопрос к Pro, возможно сломаются ассоциации, или ещё что-то... А так - это не сложно.

Кстати, в чем идея разделения /bin и /sbin ? В PFS-utils в /sbin лежит то, что надо запускать от root, а то что в /bin - не обязательно.
Надо бы права соответствующие прописать, вопрос - какие (я в этом вопросе не очень разбираюсь) ?

[sfs]

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

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

Нет, не надо. Достаточно при сборке пакетов создавать (автоматом или руками) корректный файл pfs.depends.

Пользователю покажут список нужных либ или модулей?
Если либ - что дальше делать юзеру? Название либы не всегда собпадает с названием модуля
Чтобы показать список модулей и нужен список файлов во всех модулях

Сборка в стиле ПМ с полным разбором зависимостей актуальна только в PR.

Это одна из задач разработки PFS-utils, в любом случае.

Я не точно выразился. Для PRA достаточно прописать руками зависимые модули и придерживаться принципа больших зависимых модулей. Если даже надо их получить по либе : pkgfile либа + pacman2pfs пакет = модуль со всеми зависимости , которые разрулил pacman
Для PR придется писать аналоги pacman и pkgfile (увязнем)
Поэтому предлагаю начать с рукописных зависимостей модулями и скрипта скачки
По любому без этого ничего не выйдет

pfsextract баг с правами - ок посмотрю сам
bin sbin http://habrahabr.ru/post/143614/. В арче sbin - симлинк

[Zay]

Пользователю покажут список нужных либ или модулей?

Список пакетов!

Скрипты lddcheck и pfsfindlibs - для сборщика пакетов, а не для пользователя.
Пользователь может вообще не вникать в вопрос с библиотеками.

Для PR придется писать аналоги pacman и pkgfile (увязнем)

Вопрос, какого функционала из pacman'а и pkgfile'а (кроме закачки из сети) сейчас не хватает в PFS-utils?


Про /bin - /sbin примерно так и думал (где-то читал об этом раньше).
Вопрос о перемещении всего в /bin остаётся открытым.

[DdShurick]

 

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

Есть смысл порыться в старом сундуке, думаю там уже есть.

[sfs]

Пользователю покажут Список пакетов!

С помощью ldd можно получить список библиотек
Для получения списка пакетов-модулей надо иметь список всех файлов в пакете (это в PRA и делает pkgfile, но выдает естественно pkg, а не pfs)
Или по итогу просмотра либ - написать пакеты руками. В PRA планирую только большие зависимости pfs. Поэтому меня устраивает руками + namcap dep-find pkgfile (если есть сомнения)

Предлагаю начать с загрузчика пакетов по рукописным зависимостям. Без этого остальное по зависимостям не имеет ценности
Дяде Шурику - спасибо. Надо изучить. Его последний шедевр (см. выше) использую. Доработал до формирования строки cp для копирования нужных библиотек. Это актуально только в PRA т.к. есть откуда копировать (pacman2pfs)

Вопрос о перемещении всего в /bin остаётся открытым.

В PRA это без вариантов. По другому не будет работать

[sfs]

Починил pfsextract (в аттаче, мое отмечено ##sfs)
Надо бы еще и права chmod так же расставить , но не знаю как их прочитать с файла в виде пригодном chmod - помогайте

Код

    find "${tmpdir}/files/${namepack}" -type d | while read i ;do
        ip="`echo "$i" |sed 's#'${tmpdir}'/files/'${namepack}'#'${tmpdir}'/pmount#'`"
        chown "`ls -ld "$ip" |sed -n 's/^[^ ]\+ [^ ]\+ \([^ ]\+\) \([^ ]\+\) .*$/\1:\2/p'`"      "${i}"
        chmod "`ls -ld "$ip" |sed -n 's/^.\(...\)\(...\)\(...\).*$/u=\1,g=\2,o=\3/; s/-//g; p'`" "${i}"
    done

А вообще, наверное вместо mkdir и cp надо rsync
Потеря прав -  это конкретная дыра в безопасности

[Zay]

Починил pfsextract (в аттаче, мое отмечено ##sfs)

Это?

Код

for i in `find "${tmpdir}/files/${namepack}" -type d` ;do
  ip="`echo "$i" |sed 's#'${tmpdir}'/files/'${namepack}'#'${tmpdir}'/pmount/#'`"
  chown "`ls -l "$ip"  |tail -1|awk '{print $3":"$4}'`" "${i}"
done

В этом варианте будут проблемы с пробелами в пути, лучше как-то так:

Код

find "${tmpdir}/files/${namepack}" -type d | while read chfile; do
  chown "`ls -l "$(echo "${chfile}" | sed 's#'${tmpdir}'/files/'${namepack}'#'${tmpdir}'/pmount/#')" | tail -1 | awk '{print $3":"$4}'`" "${chfile}"
done

Правильно я понял идею? Так будет работать?

Надо бы еще и права chmod так же расставить , но не знаю как их прочитать с файла в виде пригодном chmod - помогайте

Тут я тоже не в курсе... Привычка работать под root'ом сказывается.

А вообще, наверное вместо mkdir и cp надо rsync

С rsync не знаком совершенно...


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

• Получения списка всех файлов в каталоге на FTP.
• Загрузки указанного файла с FTP (желательно с консольным прогрессбаром).

[DdShurick]

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

• Получения списка всех файлов в каталоге на FTP.
• Загрузки указанного файла с FTP (желательно с консольным прогрессбаром).

Список curl -l <url>, только каким боком это к зависимостям?
Загрузка rxvt -e wget <url>/file