PFS-utils на github

[ander]

отправил pull request, жду, что дальше будет

[sfs]

А что должно быть (хотелось бы)?

[ander]

Ожидается, что кто-то, имеющий доступ до pfs-utils/pfs-utils на github увидит этот request и либо сделает merge, добавив таким образом мои правки в основной репозиторий, либо напишет что-то в ответ: типа, что вот эта строчка подойдет, а вот эта не нравится и надо вначале поправить, а уж потом сливать.

[neobht]

Это не некто мифический. Этот человек - Zay. Я считаю, только он сейчас может это делать.

[ander]

Возможно и так.  Я думал, может он еще кому-то давал доступ.  Собственно, сам request со всеми моими коммитами должен быть всем виден, репозиторий-то открытый.  Реальные изменения решил все же делать в ветке testing, думаю, ему так будет проще слить в свой testing, а потом уж разбираться дальше.

[Zay]

Принял Pull Request от ander в ветку testing. Вроде бы всё прошло без проблем!

Конкретно по изменениям pfsload чуть позже буду сравнивать.

Реальные изменения решил все же делать в ветке testing, думаю, ему так будет проще слить в свой testing, а потом уж разбираться дальше.

Думаю - это правильное решение.

Хоть я и считаю GitHub отличным средством разработки, но вести обсуждение привык всё же на форуме.
Чуть позже создам специальную тему для обсуждения деталей и коммитов.

Отдельное спасибо и + ander-у за ясные и подробные комментарии к коммитам! Все бы делали так.

[sfs]

https://github.com/pfs-utils/pfs-utils/pull/5

добавил ключи к pfsload, чтобы монтировать можно было не только в /mnt/.modname,

pfsload --no-hide
Какой в этом практический смысл?

[ander]

А вот захочется, чтобы все было в одном месте и единообразно -
то есть смонтировать туда же, куда initrd монтирует:

pfsload --nh /mnt/home/pra1511g/optional/Libreoffice-p-5.0.0-s01.pfs  /mnt/live/memory/images

[sfs]

Не вижу от этого особой пользы. Нужны ли лишние усложнения...
Все это надо тестировать. А у нас с этим плохо. Хоть какое-то тестирование происходит только после попадания в исо
Давайте чтоли две ветки pfs поддерживать - стабильную (багфикс + неоспоримые улучшения)
и тестовую (--nh  и т.п.)

[neobht]

--nh - это новый функционал.
просто не используйте его и будет та же самая стабильность.

две ветки держать стоит только в целях разработки.

[sfs]

--nh - это новый функционал.
просто не используйте его и будет та же самая стабильность.

...если он не даст побочных эффектов, что можно выяснить только тестированием

[ander]

Понятно, что тестировать надо.  Кому бы вот только подсунуть 
Все изменения делаю только в ветке testing, причем в своей, Zay только часть коммитов слил.
Свежие дополнения: подключение/отключение с копированием в память может делаться той же парой утилит
pfsload/pfsunload, для чего pfsload понимает дополнительный ключ -m или --memory
Сделано попроще, чем в pfsramload, отдельная tmpfs на каждый файл не создается, файл просто копируется в существующую, если там места хватает.

[DdShurick]

Кому бы вот только подсунуть 

Мне подсуньте, только потом плакать придётся.

Свежие дополнения: подключение/отключение с копированием в память может делаться той же парой утилит
pfsload/pfsunload, для чего pfsload понимает дополнительный ключ -m или --memory

Смысл? Разве что при загрузке по сети. К тому-же есть load_sfs и unload_sfs вполне достаточные для пользователя.
К сожалению не имею возможности работать с github после замены жёсткого диска, не пускает 

Сделано попроще, чем в pfsramload, отдельная tmpfs на каждый файл не создается, файл просто копируется в существующую, если там места хватает.

Это правильно.

[sfs]

Как в итоге мне сейчас обновлять pfs-util в PRA? И надо ли это делать?
На мой взгляд ПРА не настолько идеален, чтобы уже вылизывать такие мелочи

Предлагаю более интересную тему - автообновление всех автозагруженных модулей
1. Стандартизировать название модулей
2. Написать скрипт, вдохновясь sfs-get и dist-up

[Zay]

Все изменения делаю только в ветке testing, причем в своей, Zay только часть коммитов слил.

Странно, я так понял что Merge был полный.
Может быть Pull Request не полный получился?
И дайте ссылку на свой форк, для сравнения.

UPD: Повторил Merge. Теперь все коммиты есть?

Свежие дополнения: подключение/отключение с копированием в память может делаться той же парой утилит
pfsload/pfsunload, для чего pfsload понимает дополнительный ключ -m или --memory

На тот момент, когда это писалось, функционал был новый и не проверенный. Поэтому разделили.
Сейчас, я думаю, можно объединить скрипты.

Сделано попроще, чем в pfsramload, отдельная tmpfs на каждый файл не создается, файл просто копируется в существующую, если там места хватает.

А вот это спорное решение. Занимать место "на диске" (в "сохранёнке") не желательно, такого эффекта пользователь не ожидает.
Идея была именно "1 модуль - 1 tmpfs". Есть свободная память - монтируем. И гарантия освобождения памяти после отключения.

Кстати, если включать этот функционал в pfsload, то надо ещё предусмотреть случай, когда RAM не хватает.
Например выводить ошибку и не монтировать, но с прарметром "принудительно" - монтировать в любом случае, если памяти не хватает - то обычным способом.

автообновление всех автозагруженных модулей

Моё мнение - автообновление любого ПО это безусловно плохая идея.

А вот простой возможности загрузки по файлов .pfs по сети в PFS-utils действительно не хватает.