PFS-utils v.4

[DdShurick]

Из моего mksavexzm:

Код

find /tmp/savesfs-root -mindepth 2 -name .wh.* | while read WH
do
F=$(echo $WH | sed 's/\/tmp\/savesfs-root//;s/.wh.//g')
	if [ -e "/initrd/pup_rw$F" ]; then
	 rm $WH #если удалённый файл заново создан, удаляем .wh.*
	else
	 [ -e "/tmp/savesfs-root$F" ] && rm -r /tmp/savesfs-root$F #если ранее сохранённый файл удалён, удаляем его.
	fi # если .wh.* относится к нижним слоям - ничего не делаем
done

[betcher]

Ингваро, может чего-то упускаю, но мне кажется что для решения ваших проблем с тенями достаточно перед тем как сохранять изменения в новый модуль мержить старый модуль с обновлениями с системным.
То есть mkpfs sys.xzm update.xzm -o newsys.xzm
после, заменяете модуль sys.xzm на newsys.xzm, update.xzm удаляете и грузитесь с сохранением в новый update.xzm. Все это можно автоматизировать например скриптом в uird.run.

[ingvaro]

Ингваро, может чего-то упускаю, но мне кажется что для решения ваших проблем с тенями достаточно перед тем как сохранять изменения в новый модуль мержить старый модуль с обновлениями с системным.
То есть mkpfs sys.xzm update.xzm -o newsys.xzm

Если каждый раз  обновления писать в новый модуль то никаких проблем с тенями я у  себя не замечал
И писал я не в pfs а еще старой утилитой от МагОС
Попробую в pfs

[betcher]

И писал я не в pfs а еще старой утилитой от МагОС

Без ключей -l и -w теней в модуле не будет, а с ключами работает аналогично dir2xzm. Тут именно логику работы с сохранениями нужно продумать, вылавливать тени не хороший вариант.

[Pro]

Как я уже говорил, у меня pfs.spec с описанием пакета уже сделан. В pfs-utils 4.2 если сделать создание пакета через mkpfs --list то образуется какой-то каталог submod

Если сделать просто mkpfs то информация о составе модуля не создается и pfs.spec лежит одинокий.

Это нормально?

[betcher]

Тут получается интересная ситуация, надо подумать как разрулить.
Для атомарного модуля списки не создаются, по этому ваш спек лежит одинокий. А когда вы добавляете --list, mkpfs видит, что папка со спеком существует и считает, что это контейнер, в атомарных модулях же этой папки нет. Отсюда и submod.
Постараюсь что-то придумать.

[Pro]

ну да, логично. может условие вставить что контейнер это когда две и более папки

[betcher]

Вроде получилось починить, за одно и некоторые специальные символы в именах модулей и подмодулей (:+=,#*). Все изменения в ветке pfsget, делать сразу в двух ветках не удобно, если пройдет проверки у вас в prar предлагаю слить бранч pfsget в мастер, кроме этих изменений там только pfsget, который на работу остальных утилит не влияет.

[Pro]

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

[betcher]

Должно добавлять если такой строки там не было. Если в спеке есть name=бла-бла или NAME=бла-бла, то добавлять не должен. Как я понимаю name это единственная обязательная строка в спеке.

[Pro]

Как я понимаю name это единственная обязательная строка в спеке.

а зачем она?

[betcher]

Кто б знал
Старался делать максимально близко к тому что было. А было только name=.

[Pro]

насколько помню, делали так (в версии 3 я даже вроде правил) что если файл уже есть, то ничего в него не добавлять, а если нету - тогда вот этот name= вписывается

[betcher]

Сделаю как скажете. Sfs, что думаете?

[sfs]

mkpfs --list

Не понял, что это... В вики и https://github.com/pfs-utils/pfs-utils-cli/blob/pfsget/project-files/usr/bin/mkpfs
Не нашел такого ключа