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

[Pro]

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

а что из скрипта usoft_sfs автоматическую проверку зависимостей не взял?
pfs.depends я точно за себя скажу что у меня нигде не будет

[sfs]

pfs.depends надо создавать скриптом. Руками мало найдется энтузиастов писать. Теоретически ldd + awk может помочь... И наверное не обойтись без списка либ во всех пакетах репы.
Непростые задачи. Может не изобретать велосипед. попробовать packman приладить к нашей репе...

[Zay]

а что из скрипта usoft_sfs автоматическую проверку зависимостей не взял?

Насколько я понимаю процесс отслеживания зависимостей, полностью автоматической проверка быть не может. Где-то же должна храниться информация, в каком пакете какие библиотеки лежат?

pfs.depends надо создавать скриптом.

Согласен полностью.
Но я такой скрипт написать не смогу, т.к. не знаю сути этой работы.

Может не изобретать велосипед. попробовать packman приладить к нашей репе...

Цитата оттуда:

Pacman написан на языке C и использует формат пакетов .pkg.tar.xz.

Очевидно, это нам не подойдёт.

[sfs]

Где-то же должна храниться информация, в каком пакете какие библиотеки лежат?

Давайте с этим определимся. Иначе дальше не продвинуться.
pfs.depends - хорошо бы пример

showsplash не будет использоваться?
Смотрю даже интернационализация появилась... Серьезно подходите.

Может в slackware тогда посмотреть ПМ... http://welinux.ru/post/4483/

[Zay]

pfs.depends - хорошо бы пример

Пример в пакете.

showsplash не будет использоваться?

Это пока под вопросом... Yad'овский splash, ИМХО, не очень удобен по сравнению с gtkdialog-splash (по крайней мере в данном случае).


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

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

[sfs]

showsplash ... Yad'овский splash, ИМХО, не очень удобен по сравнению с gtkdialog-splash.

Чем именно? В конфиге showsplash можно выбрать gtkdialog

Нужен скрипт, на выходе которого должен быть список пакетов (отсутствующие зависимости), вариант такого скрипта - pfsdepends.

Получается pfsdepends без pfs.depends бесполезен.
Добавить pfs.depends во все пакеты руками никто не возьмется.
Получается нужен скрипт mkpfsdepends ,который на входе имеет папку с примонтированным .pfs , на выход через ldd выведет подобие pfs.depends. Это уже будет шаг вперед. Вдохновляться скриптами Дяди Шурика. В идеале - чтобы он и сделал... Можно на Вас рассчитывать?

[Zay]

...на выход через ldd выведет подобие pfs.depends. Это уже будет шаг вперед.

Реализовать можно разными способами.
ИМХО, проще всего обрабатывать каталог как пакет ещё до запуска mkpfs.

Логика работы может быть такой:
1. Просматриваем каталог, выясняем какие библиотеки нужны (самое сложное).
2. Ищем по файлам '/etc/packages/*/*/pfs.files' (или ещё где-то) к каким пакетам эти файлы относятся.
3. Создаем файл pfs.depends из полученного списка.

[sfs]

1. find + ldd. Хотя бы вывести недостающее в консоль - уже удобно
2. без списка всех либ во всех пакетах останется только гадать libssh находится в пакете libssh или ssh. Главный ? - этот список будет? Или какие тут варианты?
Хорошо бы дождаться ответа Дяди Шурика - он самый опытный по зависимостям.

[DdShurick]

И наверное не обойтись без списка либ во всех пакетах репы.

Давно есть

Может не изобретать велосипед.

Именно это вы и делаете.

[sfs]

lib.list ,наверное, формировался gaff. Возможно ли такой же файл сформировать для pfs?
Про велосипед: если взять get_pet и переписать расширение и распаковку пакета на его подключение - не то ли это что мы хотим...

[DdShurick]

lib.list ,наверное, формировался gaff. Возможно ли такой же файл сформировать для pfs?

Для просмотра содержимого *.pet используется tar -tf, а что для *.pfs?

если взять get_pet

Есть ещё заброшенный мной (ИМХО за ненадобностью) build_sfs.

[Pro]

ну самое низкоуровневое unsqushfs -l
а из скриптов pfs тоже вроде какойто умеет показывать содержимое.... pfsinfo чтоли ...

ps. вобще для таких целей надо бы использовать мощь содержимого /etc/packages на предмет проверки наличия нужного в системе.

[sfs]

Для просмотра содержимого *.pet используется tar -tf, а что для *.pfs?

Аналогичную задачу решал для mc (/usr/libexec/mc/extfs.d/squashfs ) + mcls
В 2х словах: примонтировать -o loop и find
unsqushfs -l - было у ilyuk. Вылезли проблемы с симлинками
Давайте переделаем get_pet в get_pfs. Специфические pfs заморочки просмотр, поиск в репе у меня и т.п. у меня решены в mc и sfs-get. Говорите что надо (типа tar -tf) на входе-выходе - переделаю в консольные утилиты.
Разбор зависимостей с Вас  

Есть ещё заброшенный мной (ИМХО за ненадобностью) build_sfs.

Для меня было загадкой - почему у get_pet с зависимостями  все ок, а  build_sfs нет. Там разный код?

[Pro]

pfsinfo дает информацию о составе составного модуля, какие в нем пакеты есть

unsqushfs -l - полный вывод списка файлов в пакете.

"примонтировать -o loop и find" - неоптимально и займет больше времени.

[sfs]

tar -tf разнообразно можно решить. Главное чтобы DdShurick в зависимости вписался. Без него будем серьезно отброшены назад. И по sh он N1 (в моем рейтинге форумчан; c его load_sfs начался мой интерес к puppurus)