Зачем переписывать - лучше доработать pfsloadДорабатывайте, а мне легче переписать.
началось... :'(А вы как хотели? Подождём, что скажет betcher.
А вы как хотели? Подождём, что скажет betcher.Дядя Шурик, сделайте новый pfsload, чтоб назывался pfsload, делал то же что pfsload (или больше), c теми же ключами как у pfsload (можно с дополнительными). И при этом был чем то лучше и я первый буду настаивать на замене. А все остальное САБОТАЖ чистой воды.
c теми же ключами как у pfsload (можно с дополнительными)Ключи абсолютно одинаковые. Дополнительные планирую.
И при этом был чем то лучшеЭто покажет только тестирование.
# ./layermanager /mnt/sda1/219/optional/Tetris.sfs
Find module OK
Check free loop OK
Check module: Squashfs version 4.0 OK
Отчёт:
Подключить mkdir -p /initrd/bundles//mnt/sda1/219/optional/Tetris.sfs && mount -o loop /mnt/sda1/219/optional/Tetris.sfs /initrd/bundles//mnt/sda1/219/optional/Tetris.sfs && mount -o remount,append:/initrd/bundles//mnt/sda1/219/optional/Tetris.sfs/ /
OK
Кстати, вы так хотели, или я неправильно понял?Вы наверное об этом.
Это интересный функционал, надо подумать где и как использовать.Может выводить это с ключиком --debug или --verbose? Hу и подключать конечно сразу.
Давайте отделим функционал pfsinstall обратно в pfsinstall и я не против замены текущего pfsload на вашЕсли там то же что в pfsload + загрузка в указвнный слой (не особо востребовано, но и не помешает). Ок - давайте тестировать
я так понял это вроде aufs-n.Это он и есть.
Пока ничего не работает, надо разбираться.Хорошо, посмотрю.
надо разбиратьсяПосмотрел:
1. Отсутствует losetup, точнее есть losetupenc, который запрятан глубоко и без sudo ничего не выдаёт, а sudo его не видит ($PATH не тот однако)ThinkPad betcher # which losetup
# which losetupА у меня почему-то нет. Правда у меня система неполная.
/sbin/losetup
# find /initrd/bundles/ -name losetup
/initrd/bundles/base/sbin/losetupтолько подсказки выводит. Так задумано?Я же с самого начала написал, что это макет. Когда всё будет отлажено, делаем команды исполняемыми и всё.
Что на счет переименования в pfsloadЯ это имя не придумывал, не мне и переименовывать. У меня изначально был load_sfs, который теперь load_xzm. Этим я тоже займусь на предмет лишнего.
и отделения функционала pfsinstall?Чем отличается подключение модуля от подключения файла-контейнера с внутренней файловой системой? Ничем. Зачем плодить сущности?
Или всеже комбайн хотите?В пределах разумного.
На заметку: найти в каком модуле файлУже есть https://github.com/pfs-utils/pfs-utils-cli/blob/master/pfs-utils-cli/usr/bin/fileinpack
Уже естьПутаете вы всё. У вас ищется pfs.files, а у меня ищется файл. Анализируя dirname можно определить в каком модуле файл даже если это не pfs.
По моему это гораздо универсальнее.Соглашусь. Надо брать :)
*.pfs можно переименовывать, а имя пакета сохраняется после сборки пакета mkpfs'ом навсегда.Значит пусть везде ищет.
Напомню что файлы *.pfs можно переименовывать, а имя пакета сохраняется после сборки пакета mkpfs'ом навсегда.Даже дважды: /etc/packages/mount/$modulename и cat /etc/packages/mount/$modulename/pfs.specs
Посмотрел код.Я тоже. Пришёл в ужас. Может быть ещё раз переписать?
Точка монтирования /mnt/dataНаследство от Puppy.
проверку зависимостей встроитьЭто запросто:
echo "ума не хватает и руки кривые" && exit 1проверку зависимостей встроитьПроверку зависимостей относительно системы или относительно только одной базы?
Относительно системы (пример):О, как Вы серьезно за дело взялись. Мы слегка о разном, как мне кажется. Имел ввиду список бинарников без которых layermanager не сможет работать.
без которых layermanager не сможет работать.mkdir, mount, umount, cp, realpath, basename, file, losetup, getopt. Всё это в MagOS есть. Проблема в проверке losetup --find, в MagOS выдаёт /dev/loop0. Это какая-то особенность porteus, надо либо исключить, либо обойти.
О, как Вы серьезно за дело взялись.Эти приёмы работы давно проверены.
mkdir, mount, umount, cp, realpath, basename, file, losetup, getopt. Всё это в MagOS есть. Проблема в проверке losetup --find, в MagOS выдаёт /dev/loop0. Это какая-то особенность porteus, надо либо исключить, либо обойти.Речь не о МагОС, речь о "непоймичем" загруженном с помощью uird. В магос в такой проверке смысла нет.
либо обойти.Обошёл. В MagOS_64 подключил фирмварь во второй слой.
речь о "непоймичем""Пойди туда, не знаю куда, принеси то, не знаю что" :(
depmodЗависимые модули?
fixmenusБудет же DE зависимо
Я правильно понял - функционала об(раз)ъединения нет?Да. Здесь работа со слоями, об(раз)ъединение это совсем другая история, работа с каталогами.
об(раз)ъединение это совсем другая история, работа с каталогами.Это будет?
Это будет?Сначала надо допилить то что есть.