pfs-get - консольный менеджер модулей.pfs .sfs

[betcher]

Т.е. можно это использовать, а можно нет

именно.

[betcher]

Попробую собрать что имеем в кучу и что планируется. Может кто идей докинет. Итак.
pfsget - скрипт для установки модулей из репы.
Репа модулей для pfsget это сетевая папка rsync + все что умеет wget + webdav (в планах), внутри папки может быть любая иерархия каталогов с модулями и два специальных файла _REPOLIST (или _REPOLIST.gz) и _REPOLIST.sig. Первый содержит имена модулей с некоторыми данными по ним, второй это gpg подпись первого. Такая конфигурация позволяет переносить всю репу с одной сетевой папки на другую без пересборки реполистов.
Требуется пересборка реполистов при изменениях в репе. Делается тем же pfsget (над генерацией данных в реполист еще надо работать).
Таким образом при скачивании модуля pfsget скачивает реполисты и подписи со всех реп, проверяет подписи по публичным ключам находящимся в сборке, далее производит поиск в общем списке со всех реп, если что-то найдено предлагает к установке. В случае если найденное вас устраивает и вы соглашаетесь модуль скачивается, вычисляется его контрольная сумма и эта сумма сравнивается с суммой записанной в подписанном реполисте. Такая схема практически исключает установку "левого" модуля.
Если модуль имеет зависимости указанные в pfs.deps - они также будут загружены и проверены.
Ключи:
    "-u" | "--update-media"  обновить реполисты
    "-f" | "--force"               не задавать вопросы
    "-i" | "--install" )            качать не в текущую папку, а в папку указанную для установки модулей (modules) и подключить
    "-l" | "--load" )              подключить после скачивания
    "-o" | "--outdir" )           куда качать
    "-s" | "--search" )          только найти
    "-g" | "--guimode" )       режим выхлопа удобный для парсинга внешней программой (например GUI для pfsget)
    "-m" | "--mkrepolist" )   генерация реполиста для репы

Частично реализовано.
Нечеткий поиск. В случае если модуль не найден в списках поиск продолжается в специальном файле куда заносятся возможные варианты поиска в том числе на русском.
Например:
pfsget браузер
Предложит вам повторить поиск с firefox, opera, vivaldi, palemoon и так далее.
Более того при наличии в системе agrep поиск будет проведен с учетом того, что в запросе есть ошибки то есть
pfsget браВзер
Предложит вам тот же список.
Сама эта система работает, нужны списки соответствий.


В ближайших планах.
Режим обновления.
pfsget ./модуль.pfs
Ищет в репе более новый (или может не новейший, а отличный от текущего) модуль. Качает во временную папку, сверяет суммы, пытается отключить текущий модуль и заменить на новый. Если отключить не получается, то заменяет не отключая и предлагает перегрузить. В случае если репа rsync имеет смысл перед скачиванием "подсунуть" предыдущий модуль. Это уменьшит траффик (при небольших изменениях обычно раза в два).
Пока не ясно по алгоритму сравнения имен модулей (см. выше)

[krasnyh]

А есть тестовая репа, чтобы проверить? А то пока на всех ключиках, только
########################################
и тишина.
Попробовал pfsget -m, создался /_REPOLIST.gz с инфой о abc123.pfs, который у меня лежал в ~/live:
.abc123.pfs VER=00.00 REV=00 DATE=2020-09-16 SIZE=4,0K MD5=8dd1fc3cc71fc28bba083d40cfbab5b7

Вроде тогда должен работать pfsget -l abc123.pfs, но нет (запускал из ~/live/Загрузки).     


А так, мне нравится наличие " -l | --load", мелочь, а удобно. А так же, что по умолчанию качает в текущую папку - часто запуская iso в ВМ, приходится переопределять в sfs-get выставленный путь /optional (который не работает с sr0) на домашнюю директорию. Тоже мелочь, но...

Код

pfsget --help                                           
/usr/local/bin/pfsget: строка 210: HLP: команда не найдена

UPD.

мне нравится наличие " -l | --load",

Это реализовано и в sfs-get, забыл. Но все равно я за консольный обеими руками.

[krasnyh]

    "-u" | "--updAte-media"  обновить реполисты

А то так и в help попадет.

[betcher]

Для локальной папки создавать реполист не нужно. Но саму папку нужно прописать в список репозиториев. Давно это не проверял, надеюсь работает.
За ошибку спасибо, исправлю.
Тестовой репы нет, могу завести в принципе. С rsync

[sfs]

Т.к. изначально хотели сделать, чтобы и с busybox работало - т.е. не раздувать - хотелось бы обойтись wget и gpg (ну или опционально)

есть тестовая репа, чтобы проверить?

http://mirror.yandex.ru/puppyrus/puppyrus-a64/pfs-portable/_REPOLIST.gz , но ,возможно  старый

[betcher]

Rsync и gpg не обязательные.
Сетевой протокол выбираете сами, подтерживаются все что держит wget + rsync. В планах webdav еще. Для реп на ЯД и прочих.
Gpg будет требовать если найдет файл sig. Но так оставлять не правильно, нужно будет делать выключатель в конфиге.

[betcher]

Есть альтернативная мысль. А что если хранить нужные значения (имя, версия пакета, версия модуля, ревизия и проч.) не в названии модуля, а внутри модуля. Логичным кажется что-то вроде pfs.spec, но не понятно как быть с контейнерами. Там может оказаться много спеков. Соответственно при обновлении репы данные читаются из спеков и записываются в _REPOLIST. Конечно все это касается только модулей которые распространяются через репозитории. То есть спек не обязателен.

С контейнерами действительно беда. Там у нас получается вообще нет места куда складывать то, что относится именно к контейнеру, а не к его подмодулям. Есть идеи? Может вообще спецификацию pfs файла переделать? Я бы папки mount/install упразднил докучи.

Тут тема мелькала, потом закрыли, по обновлению iso. Так pfsget это половина работы уже. Ему не важно модуль это или ядро например. Обновлятор для всего дистра получится достаточно простым скриптом. Алгоритм приблизительно такой. Добавляете в дистр файл с версией /prar/version -  метка чтоб понять что пора обновляться. На сервере в отдельной папке вся сборка в распакованном виде. Скрипт качает новый _REPOLIST, сравнивает контрольные суммы локального и удаленного version (или сами файлы). Если отличаются создает папку prar_new и выкачивает туда новую версию с репы. Лучше даже  cp prar prar_new с rsync качать надо будет много меньше, и не нужно отдельно переносить сохраненки и прочее "свое". В случае успеха останется только переименовать prar -> prar_old и prar_new -> prar и перегрузить. В случае неудачной загрузки обновлений, перезапуск скрипта и тут опять выгоднее rsync. В случае если сами обновы косячные можно загрузиться с prar_old. И все это с подписями и проверками контрольных сумм, то есть достаточно надежно и секурно.
З.Ы. Есть наработки и по полной сборке дистрибутива скриптами. Делал такую сборочную для магос-подобной сборки. На входе лайв дистра репозиторий которого используете, на выходе готовая сборка со всеми обновлениями и несколько отдельно собираемых модулей. Сборка "нахолодную" - часа 3 занимала, пересборка - час. Скрипты показать не смогу, тем более там urpmi и все равно переписывать, но рассказать могу очень подробно. На всю работу от идеи до стабильной пересборки ушла неделя где-то. Мне кажется вам этого не хватает. Если выложить скрипты в гит получится совместная работа, а не перекидывание каждой минимальной правки через форум и sfs.

[sfs]

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

/etc/packages/mount/имя_контейнера.spec ?

Может вообще спецификацию pfs файла переделать?

C потерей совместимости?

Я бы папки mount/install упразднил докучи

У себя не нашел

по обновлению iso

Как-то сложно и так же не понятно, чем это лучше обычной фругал установки с обычным автообновлением...

Есть наработки и по полной сборке дистрибутива скриптами.

Дистры старее прар2008 у меня достаточно рукодельные. В прар я постепенно иду к этому - все уже опакечено
Но тороплюсь не очень. Мне и так удобно. Среди юзеров сборщиков не выявлено

Если выложить скрипты в гит получится совместная работа,

не с кем, к сожалению

не перекидывание каждой минимальной правки через форум и sfs.

Чем плохо автообновление модуля и как тут поможет гит...

[DdShurick]

С контейнерами действительно беда.

Мне мыслится так: атомарный модуль - pfs.files, контейнер - pfs.list (список вложенных атомарных модулей). Тогда всё логически решается.

[betcher]

/etc/packages/mount/имя_контейнера.spec ?

Возможно. Надо смотреть что произойдет при склейке контейнеров с такими спеками и еще мне не нравится, что у атомарного модуля со спеком для репы и у контейнера со спеком эти спеки будут в разных местах.
/etc/packages/mount/имя_контейнера.spec
/etc/packages/mount/имя_модуля/pfs.spec
Может быть ввести специальный файл который используется только для репы и пфсгет и при склейке просто теряется? Как заменитель для "правильного" имени модуля, которые вы не хотите адаптировать для надежного парсинга.

C потерей совместимости?

Вероятно да.

У себя не нашел

/etc/packages/mount/
/etc/packages/install/
Зачем эти папки? Почему нельзя сразу в /etc/packages? А инсталленые модули помечать меткой
/etc/packages/имя_модуля/.installed
Или просто искать модуль в aufs-n если отсутствует, значит инсталленый.
Не то чтобы это прям проблема, просто при склейке эти папки mount попадают в submod и множатся с каждым уровнем вложенности.

Как-то сложно и так же не понятно, чем это лучше обычной фругал установки с обычным автообновлением...

У вас есть автообновление сборки? Не знал. Думал только модули обновляются.

Чем плохо автообновление модуля и как тут поможет гит...

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

[betcher]

Мне мыслится так: атомарный модуль - pfs.files, контейнер - pfs.list (список вложенных атомарных модулей). Тогда всё логически решается.

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

[sfs]

/etc/packages/mount/
/etc/packages/install/
Зачем эти папки? Почему нельзя сразу в /etc/packages?

Вспомнил. Это установленные (т.е. распакованные). Поэтому у меня и нет

инсталленые модули помечать меткой
/etc/packages/имя_модуля/.installed

чем это по итогку будет лучше? Искать неудобно

У вас есть автообновление сборки?

автообновления исо нет. Есть только модулей для фругал и pacman -Suy для фул

[betcher]

чем это по итогку будет лучше? Искать неудобно

Да эта инсталляция вообще побочный функционал, лучше будет тем что структура каталогов проще. На самом деле мешает не особо, заморачиваться такими "улучшениями" стоит только если будет реальный повод для изменения спецификации с нарушением совместимости. Короче пусть живет пока

[sfs]

пусть живет пока

Да. Как-то маловато плюсов на выходе...