Форум проекта PuppyRus Linux
Разработки проекта PuppyRus => PFS-utils => Разработка PFS и Initrd => Разработка PFS-utils v.4 => Тема начата: sfs от 19 Апрель 2018, 10:35:39
-
По итогу (http://forum.puppyrus.org/index.php?topic=14803.msg142974#msg142974)
Плохая идея - объединять составные модули mkpfs -m
На выходе задвоения списков. Особенно если модуль собран под одним именем, а потом переименован
Оптимально все распаковать и mkpfs -d
По идее можно оформить как ошибку. Если не сохранить исходные модули - разобрать потом "составной pfs из составных pfs" будет проблемно...
-
Напрашивается два варианта. Первый, самый простой, а может и правильный - объединять составные модули как простые. То есть не сохранять списки для подмодулей. И второй вариант сохранять списки для каждого подмодуля, но не делать новые списки для объединяемых контейнеров. Тогда двоиться списки не должны, даже после переименования. А если хранить все и создавать новые списки, то будет двоиться мне кажется.
-
самый простой, а может и правильный - объединять составные модули как простые.
Плохая идея. Теряется возможность разборки на молекулы (если модуль не из пакетов)
второй вариант сохранять списки для каждого подмодуля
Так бы хорошоесли хранить все и создавать новые списки, то будет двоиться
Сейчас примерно так и получается
-
Посмотрел как у нас сейчас получается. Если склеить два контейнера то в итоговый модуль попадут списки для всех сабмодулей и для исходных контейнеров тоже. То есть можно извлечь любой сабмодуль и контейнер тоже можно извлечь. Но. Списки для контейнеров не содержат списков для сабмодулей. То есть если извлечь из итогового контейнера один из входящих контейнеров, то он окажется обычным модулем без списков сабмодулей. Нужно ли что-то чинить? Вроде норм. И не двоилось ничего.
-
Если склеить два контейнера то в итоговый модуль попадут списки для всех сабмодулей и для исходных контейнеров тоже. И не двоилось ничего.
Получается - если разобрать итоговый пфс полностью - один и тот же файл окажется в двух модулях (время место теряем зря)
Причем информация о том, какие одиночные модули входили в склеенный составной все равно утеряна
Для чего такой модуль... Уж лучше его из одиночных пересобрать... Только список придется угадать (сравнить со склеенным составным)
В идеале было бы логично получить исходные составные модули (которые потом еще можно разобрать)
Иначе получается - главная идея убита : не все что собрано можно разобрать ...
-
В идеале было бы логично получить исходные составные модули (которые потом еще можно разобрать)
Иначе получается - главная идея убита : не все что собрано можно разобрать ...
Наверное трудно будет провернуть такое для любой степени вложенности. Надо подумать, было бы прикольно конечно.
-
для любой степени вложенности
Думаю, достаточно 2 уровня
-
Думаю, достаточно 2 уровня
Ну тут логичный вопрос, а что делать если объединяем двухуровневые контейнеры?. Наверное проще будет все же придумать универсальное решение, а если не получится хранить списки только для атомарных модулей, а для контейнеров не сохранять.
-
Вроде получается, но ломает достаточно много. Надо проверять и чинить.
Отправил в гит, бранч v4. Ломать в мастере не стал.
Склеивает контейнеры с любой вложенностью. При распаковке разделяет по последней склейке. Достать подмодуль из ранних чем последняя склейка контейнеров пока не получится, но теоретически проблем нет. Пробуйте, интересно вроде, не знаю только надо это кому или нет :))
-
Извлечение любых по глубине сабмодулей тоже запилил.
Смотрите как сабмодуль называется в pfsinfo contaner.pfs и дальше как обычно.
Названия приблизительно такие:
сабмодуль1:сабмодуль2:сабмодуль3:модуль
-
Отправил в гит, бранч v4. Ломать в мастере не стал.
Очень правильно
На самом деле такой функционал нужен не всегда и не всем. Поэтому - если решение сложное - надо ли вообще...
Я в пра перешел на сборку pfs из пакетов. С пакетами можно делать метапакеты (без файлов - только со списком пакетов). Так удобнее и проще. Т.е. разборка pfs почти не нужна
Протестировал в4
selftest проходит
собрал составной 1234 из друх составных 12 и 34 -норм
pfsextract 1234.pfs = 12.pfs + 34.pfs - норм.
pfsextract 12.pfs 34 -норм
pfsextract -d 1234.pfs = диры 12 и 34 ,т.е. инфа про то что они составные утеряна
Не лучше ли здесь было получить диры 1 2 3 4
-d наиболее востребованный вариант
В аттаче модулт с утил в 4 и модуль для тестов
-
На самом деле такой функционал нужен не всегда и не всем. Поэтому - если решение сложное - надо ли вообще...
Там не сложно, но заранее не известно где аукнется. Сейчас пока менял только mkpfs, pfsextract, pfsinfo, pfs(mklist). Проверял только самый стандартный вариант сборку из модулей и разборку в модули. Ограничений на количество вложений нет, как устроено легко понять если сделать глубоко вложенный контейнер и заглянуть у него в $PFSDIR. Думаю надо допилить не торопясь, тем более, что для обычных контейнеров, состоящих из атомарных модулей вообще ничего не меняется.
pfsextract -d 1234.pfs = диры 12 и 34 ,т.е. инфа про то что они составные утеряна
Не лучше ли здесь было получить диры 1 2 3 4
-d наиболее востребованный вариант
По разборке в папки даже не думал еще. Может делать аналогично модулям, то есть с сохранением PFSDIR? Или разбирать сразу на атомы?
З.Ы. еще косяк нашел. Извлечь за раз более одного сабмодуля не получается. Либо все, либо один.
З.З.Ы Попробуйте склеивать контенеры с разной степенью вложенности. Или контейнер склеивать с атомарным модулем. Тоже должно работать. Главное смотреть названия через pfsinfo. Нормально, кстати, через ":" ? как вариант можно еще "::" сделать разделителем или "->"
-
надо допилить не торопясь
да. Только в3 отладили...
По разборке в папки даже не думал еще. Может делать аналогично модулям, то есть с сохранением PFSDIR?
А смысл? если собрать mkpfs он это убъет
Ну или допилить чтобы не убивал
Или разбирать сразу на атомы?
Мне кажется так лучше...
Хотя надо бы не теоретические задачи, а практические
Может по итогу придет понимание что это вообще не нужно...
контейнер склеивать с атомарным модулем.
Проверил - норм
-
Может в packages делать подкаталог для каждого составного модуля со списком пакетов, а в packages/mount все пакеты из всех модулей составных.
При объединении двух составных модулей, их состав будет отражен в /packages (вместо файлов можно просто ссылки на соответствующее содержимое /packages/mount)
-
Я сделал немного иначе, вариант хорош тем, что для обычных модулей и контейнеров сделанных из обычных модулей ничего не меняется. Во время сборки модуля перед созданием списка проверяется не содержит ли модуль уже PFSDIR/mount. Если каталог есть он копируется в PFSDIR/modules/packname/submod/ для будующего модуля. Если склеивать снова копирование произойдет снова увеличивая вложенность submod/mount. При распаковке сдвиг в обратном порядке.
Сложно словами описать, загляните внутрь контейнера с большой глубиной склеек. И pfsinfo контейнер.pfs думаю сразу станет понятно. То есть для хранения информации о вложенности используется дерево fs. Типа как в proc и sys.
-
ну да я понял, нормально
-
По распаковке в папки вижу два варианта.
1. Папки никогда не содержат списков. Тогда:
- pfsextract -d contaner.pfs -> распаковать на папки соответствующие атомарным модулям. То есть по максимуму в глубину.
- pfsextract -d submodule contaner.pfs -> собрать в папку файлы соответствующие submodule не зависимо от того контейнер это или обычный модуль. Без списков, то есть если submodule был контейнером в папке информации об этом не будет.
2. Папки полностью соответствуют модулям по файлам. Тогда:
- pfsextract -d contaner.pfs -> разобрать на один шаг в глубину. Каждая получившаяся папка будет содержать списки своих подмодулей, Можно сделать из нее сквош и разбирать дальше. В идеале научить pfsextract разбирать папки-контейнеры.
- pfsextract -d submodule contaner.pfs -> если submodule это контейнер, то списки есть, если атомарный модуль то списков нет. То есть как и у модулей сейчас.
Оба варианта по своему не полохи. Как делать будем?
-
pfsextract -d contaner.pfs -> распаковать на папки соответствующие атомарным модулям. То есть по максимуму в глубину.
Думаю - этого достаточно. как они были объединены покажет pfsinfo
Каждая получившаяся папка будет содержать списки своих подмодулей, Можно сделать из нее сквош
mksquashfs ?
mkpfs сделает из папки с распакованным составным- одиночный модуль
Остальное - лишние усложнения
Например есть составной1 - браузер + либы. Хочу добавить к нему одиночный1 (забыл либу)
mkpfs = составной2
При следующей пересборке разбираю на атомы. Обновлюя версию браузера. Собираю составной3
надо бы не теоретические задачи, а практические
Может по итогу придет понимание что это вообще не нужно...
Давайте придумаем реальные задаси и будем их решать
-
То есть склоняетесь к варианту номер раз?
-
Да и можно даже без pfsextract -d submodule contaner.pfs
Проще разобрать на атомы и собрать из них любой составной
-
Проще разобрать на атомы и собрать из них любой составной
Проще, но сложнее с зависимыми библиотеками.
-
Да и можно даже без pfsextract -d submodule contaner.pfs
Если запилить разбор на атомы для каталогов это само заработает.
Проще, но сложнее с зависимыми библиотеками.
Вот тут бы подробнее, не понимаю. И вообще как Вы считаете правильнее сделать?
-
Вот тут бы подробнее
Пример: имеем в модуле два пакета с программами и два с зависимыми библиотеками. Какие библиотеки к какой программе? Без рук не обойтись.
И вообще как Вы считаете правильнее сделать?
Не знаю. Собираю руками, даже своя программа работы с модулями не прижилась.
-
Пробуйте pfsextract -d.
Интересный момент возник. Сабмодули на разной глубине могут иметь одинаковое имя. Добавил для двойников имя _$RANDOM к имени модуля или каталога если с -d. Момент редкий не стал городить имя_$(( n+1 )).
-
имеем в модуле два пакета с программами и два с зависимыми библиотеками. Какие библиотеки к какой программе?
Логично было бы это иметь двумя составными модулями
А вообще - тема зависимостей внутри пфс - это проблема конверторов пакет-модуль или сборщика модуля
Задача псф - сборка - разборка. Ничего более
Поэтому я и призываю : практическая задача - решение
Реализовывать теоретически возможные варианты - усложнение + ошибки
-
практическая задача - решение
Голова - руки.
-
Усложнение не коснулось ни модулей ни контейнеров. Только склеенных контейнеров, которые до этого вообще не предполагались. Будем делать в v4, пока совсем стабильно не станет.
-
Напрашивается два варианта.
И оба с изъянами. В первом случае получаем "кашу", во втором - дублирование списков. Может проще сделать список входящих в модуль "атомов", например pfs.packs? При разборке составного модуля прогоняем этот список через цикл, читающий списки "атомов". Идея понятна?
-
Совсем не понятна идея.
И в чем каша? Контейнер хранит всю инфу по поводу того что и куда вложено. При распаковке в модули по умолчанию разбирает на один шаг назад. При распаковке в папки по умолчанию разбирает на атомы. Вроде так решили. При указании сабмодуля или нескольких сабмодулей распаковывает только их, при этом в распакованных модулях все списки будут, а в папках всегда списков нет. Вроде норм.
Кстати, уже так работает. Хорошо бы проверить в пра.
-
Хорошо бы проверить в пра.
Проверил - норм. Меня все устраивает
-
Сделал прототип с сохрвнением дублирующихся файлов. Пока не отключаемо. Тестил мало. Попробуйте на предмет тормозов.
-
Не смотрели еще?
-
с сохрвнением дублирующихся файлов
Есть сомнения в нужности такого функционала вообще
Т.е. если такие файлы есть - кто-то накосячил. Максимум вывести ошибку
-
ть сомнения в нужности такого функционала вообще
Т.е. если такие файлы есть - кто-то накосячил. Максимум вывести ошибку
С одной стороны вроде да. Но если мы склеили два модуля, то хотелось бы при расклейке получить ровно такие же. А сейчас это не так.
Можно выкинуть эту проверку, можно под ключик убрать, можно наоборот оставить по умолчанию, но не проверять с ключем -f. Как поступим?
З.Ы. Сам не уверен надо ли. Хотелось бы еще мнений. Вкраце мысль такая mkpfs bash_3 bash_4 -o bash.pfs, получаем модуль при подключении которого работать будет bash_4, но pfsextract разберет обратно на bash_3 и bash_4. А если оставить как сейчас то при разборке получим модули bash_3 и bash_4, но ро факту будет везде bash_4.
Надеюсь не запутал окончательно :)
-
Если работает -
под ключик убрать
хорошо бы отдельной функцией, чтобы основной код не загромождать
-
Можно функцию даже в pfs вынести. Какой ключ? По смыслу - "сохранять дубликаты".
-
-d занято. -s ?
-
S от save?
-
--duplicates ?
-
--looseless ?
-
--save-duplicates ?
-
--save-duplicates
Да, пожалуй самое понятное. Единственное что речь не совсем о дубликатах, а об отличающихся файлах с одинаковым именем. Если больше ничего не придумается так оставим.
-
Вроде работает. В pfsextract под ключ убирать не стал так как дополнительно тормозить не должно, если файлы сохраненные есть то копирует.