а там глядишь и обсуждение пойдет.Ох :( В этом я не сомневаюсь.
Пока не ясно что делаемУтилиты :) Но вот для кого?
1. какие утилиты?Надо написать:
расширения модулейБез разницы. Работает с dir, img, sfs|pfs|zxm|....
совместимость с чем?Со здравым смыслом ;)
Надо написать:Создание метадаты, создание aufs, и подключение слоя я бы в один файл собрал. В либу. Они вспомогательные и отдельно от этих утилит применения не имеют.
- Утилита создания метадаты при запаковке модуля - mksqmod
- Слияние простых и составных модулей - mergesqmod
- Извлечение простого модуля из составного - extractsqmod
- Редактирование простых и составных модулей - editsqmod
Уже есть:
- Создание вспомогательной aufs - mkaufs
- Подключение слоя в aufs - addlayer
Цитата: betcher от Сегодня в 05:18:56
Создание метадаты, создание aufs, и подключение слоя я бы в один файл собрал. В либу.Вопрос спорный, думать надо.. Применение библиотек не всегда оправдано.
extractmod по мимо распаковки составных думаю стоит научить распаковывать обычныеДля простых модулей unsquashfs проще и эффективнее.
Для простых модулей unsquashfs проще и эффективнее.Не спорю. Скрипт это и будет делать. Просто название наталкивает на мысль, что как бы должен. А учитывая что составные теперь он может разложить до каталогов почему бы не распаковать одиночный?
Вопрос спорный, думать надо.. Применение библиотек не всегда оправдано.Кроме перечисленных еще куча мелочи будет вроде fstype, тоже отдельными файлами? 10 трехстрочных скриптов, которые являются вспомогательными и отдельно не применяются тоже не айс. Проект pfs-utils с первого взгляда так и выглядел. Три десятка скриптов, полтора десятка ссылок, что зачем не понятно. Как сейчас гораздо аккуратнее. Либу кстати можно держать в /usr/bin тогда сохранится возможность sqmfunc addlayer 1 /my/module (sqmfunc это я либу так обозвал).
почему бы не распаковать одиночный?Строки из pfsedit:
PACKS=$(unsquashfs -l "$1" -e /$METADIR | awk -F/ '/mount/ {print $5}' | sort -u)
[ "$(echo $PACKS | wc -w)" -gt 1 ] || msgerr "The module is not composite"
Кроме перечисленных еще куча мелочиЯ это не писал и переписывать не собираюсь. У меня куча мелочи есть?
Вместо сообщения ставим unsquashfs, вот вам и "предсказуемое поведение"Все так, только edit - это редактировать. А extract - извлекать. По этому предсказуемо это именно в той утилитке. Но вообще это неважно, настаивать не стану.
У меня куча мелочи есть?У вас пока особо ничего нет и пока не понятно что будет. А на примере того что есть - pfs-utils - вычленить общие части можно и не мало, то что сейчас в libpfs это только половина и в основном костыли. Но опять же настаивать именно на либе не буду. Тем более пока нет самих скриптов выводы делать рано.
Все так, только edit - это редактировать. А extract - извлекать.Edit будет переписываться, Extract ещё не написан.
У вас пока особо ничего нет и пока не понятно что будет.Это потому что я предпочитаю работать руками. Но что-нибудь будет.
Писать новые утилиты с тем же функционалом не надо и это вредно.Вредно пить и курить, писать утилиты не вредно.
Я считаю это все не надо.А придётся. Здесь другой принцип, создание вспомогательной aufs.
Надо сделать pfs-utils такими, которые дадут нужные функции для решения задач.Я к тому и веду, что нужно просто переписать с учетом новых идей то, что есть. А на период пока будем это делать заморозить ветку. Для всех будет проще и понятнее если с точки зрения пользователя изменений будет не много. Если хотите отойти именно от pfs, давайте сменим префикс sqmload sqmextract
Ничего, кроме улучшения pfs-utils делать не нужно в этом направлении.
Писать новые утилиты с тем же функционалом не надо и это вредно.
нужно просто переписать с учетом новых идей то, что есть.
Проект pfs-utils с первого взгляда так и выглядел. Три десятка скриптов, полтора десятка ссылок, что зачем не понятно.Вам очень хочется с этим разбираться?
Я считаю это все не надо.Я с самого начала знал, что будет забалтывание. Пожалуй брошу я это дело.
Вам очень хочется с этим разбираться?С этим разобрались уже.
Я с самого начала знал, что будет забалтывание. Пожалуй брошу я это дело.Не забалтываем, а как раз наоборот ищем путь который устроит всех. Чтоб вы не писали что называется в стол. Не жаль трудов?
ищем путь который устроит всех.Ну и чем вас не устраивает моя писанина?
С этим разобрались уже.Путём объединения мелочи в одну большую либу? Этот путь порочен.
Применение библиотек не всегда оправдано.Когда не оправдано, если есть повторы кода?
Для простых модулей unsquashfs проще и эффективнее.unsquashfs без ключей даст squashfs-root. Для использования в ФМ удобнее скрипт с выходом в виде папки `basename *.pfs .pfs`
Ничего, кроме улучшения pfs-utils делать не нужно в этом направлении.В свете последних идей , которые обязательно надо реализовать - может так получиться, что некоторые скрипты pfs-util проще переписать, чем править - что Дядя Шурик и делает
Писать новые утилиты с тем же функционалом не надо и это вредно.
брошу я это дело.Погодите - я еще не протестировал Вашу альтернативу. Остальные протестировали?
сделать все поперек.С моей точки зрения это вы перпендикулярны, а Антон вообще в четвёртом измерении
Есть привычный многим набор утилитИ много этих многих?
ибо багажник - порочный путь.Да. Причём не только в данном случае, а для всего Linux. Подумайте на досуге, отчего всё тормозит?
Когда не оправдано, если есть повторы кода?Повторы выносятся во внутреннюю функцию, если в нескольких скриптах - тогда в библиотеку, но вызывать из трёхстрочника тысячестрочную библиотеку ради одной функции это уже перебор. Прицепите к велосипеду трейлер, и он не поедет.
unsquashfs без ключей даст squashfs-root.А что мешает unsquashfs -d `basename *.pfs .pfs` *.pfs ?
ПогодитеЯ имел в виду брошу обсуждение, ибо бесполезно.
заменить pfs на sqmТипа милицию в полицию. Как будто остальное идеально и заняться больше нечем :)
по ключам и утилитам берем то что есть в pfs-utils, и для каждого конкретного скрипта обсуждаем.да
Вот, еще один шажок вперед.
Если так уж хочется избавиться от наследия pfs, предложу еще раз во всех названиях заменить pfs на sqm, aka SQuashfs Module. А по ключам и утилитам берем то что есть в pfs-utils, и для каждого конкретного скрипта обсуждаем. Что убрать, что добавить что изменить. Либу можно наполнять по мере появления дублирования в коде. Кстати, посмотрите чего мы с, sfs, решили по ее поводу. Кмк, вполне себе компромис.
З.ы.Может потому и тормозит, что бездумно оптимизируюттормозит обычно из-за того, что до ума не доводят потому что свои мелкие велосипеды считают лучше других велосипедов.
заменить pfs на sqmСходно мыслим :) Огласите весь список пожалуйста.
Не нужно менять название, потому что утилиты должны оперировать не только squashfs модулями, но и RWM, ROM и директориями.Вот как-раз поэтому и нужно менять название, ибо pfs-utils "pfs only"
Нужны нормальные скрипты для того, чтобы не запоминать параметры для монтирования кучи слоев в кучи вариантах - должно быть просто и легко и достижимый результат.Вот я к этому и стремлюсь.
тормозит обычно из-за того, что до ума не доводят потому что свои мелкие велосипеды считают лучше других велосипедов.Какая связь между умом и велосипедами? Кстати велосипеды (https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4) развиваются в сторону облегчения.
Если хотите критиковатьЕсли бы. Иногда крыть хочется. :( Особенно когда тебя не понимают.
создал документ GoogleКак посмотреть? Чем вики не подходит?
никак не посмотреть, если нет аккаунта на гугле.создал документ GoogleКак посмотреть? Чем вики не подходит?